1 //===---------------------------------------------------------------------===//
2 // Random ideas for the X86 backend: SSE-specific stuff.
3 //===---------------------------------------------------------------------===//
5 //===---------------------------------------------------------------------===//
7 SSE Variable shift can be custom lowered to something like this, which uses a
8 small table + unaligned load + shuffle instead of going through memory.
11 .byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
12 .byte -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
15 __m128i shift_right(__m128i value, unsigned long offset) {
16 return _mm_shuffle_epi8(value,
17 _mm_loadu_si128((__m128 *) (___m128i_shift_right + offset)));
20 //===---------------------------------------------------------------------===//
22 SSE has instructions for doing operations on complex numbers, we should pattern
23 match them. Compiling this:
25 _Complex float f32(_Complex float A, _Complex float B) {
34 pshufd $16, %xmm2, %xmm2
35 pshufd $1, %xmm1, %xmm1
36 pshufd $1, %xmm0, %xmm0
38 pshufd $16, %xmm0, %xmm1
46 //===---------------------------------------------------------------------===//
48 Expand libm rounding functions inline: Significant speedups possible.
49 http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00909.html
51 //===---------------------------------------------------------------------===//
53 When compiled with unsafemath enabled, "main" should enable SSE DAZ mode and
56 //===---------------------------------------------------------------------===//
58 Think about doing i64 math in SSE regs on x86-32.
60 //===---------------------------------------------------------------------===//
62 This testcase should have no SSE instructions in it, and only one load from
65 double %test3(bool %B) {
66 %C = select bool %B, double 123.412, double 523.01123123
70 Currently, the select is being lowered, which prevents the dag combiner from
71 turning 'select (load CPI1), (load CPI2)' -> 'load (select CPI1, CPI2)'
73 The pattern isel got this one right.
75 //===---------------------------------------------------------------------===//
77 SSE should implement 'select_cc' using 'emulated conditional moves' that use
78 pcmp/pand/pandn/por to do a selection instead of a conditional branch:
80 double %X(double %Y, double %Z, double %A, double %B) {
81 %C = setlt double %A, %B
82 %z = fadd double %Z, 0.0 ;; select operand is not a load
83 %D = select bool %C, double %Y, double %z
95 ucomisd 40(%esp), %xmm1
105 //===---------------------------------------------------------------------===//
107 Lower memcpy / memset to a series of SSE 128 bit move instructions when it's
110 //===---------------------------------------------------------------------===//
113 if (copysign(1.0, x) == copysign(1.0, y))
118 //===---------------------------------------------------------------------===//
120 Use movhps to update upper 64-bits of a v4sf value. Also movlps on lower half
123 //===---------------------------------------------------------------------===//
125 Better codegen for vector_shuffles like this { x, 0, 0, 0 } or { x, 0, x, 0}.
126 Perhaps use pxor / xorp* to clear a XMM register first?
128 //===---------------------------------------------------------------------===//
130 External test Nurbs exposed some problems. Look for
131 __ZN15Nurbs_SSE_Cubic17TessellateSurfaceE, bb cond_next140. This is what icc
134 movaps (%edx), %xmm2 #59.21
135 movaps (%edx), %xmm5 #60.21
136 movaps (%edx), %xmm4 #61.21
137 movaps (%edx), %xmm3 #62.21
138 movl 40(%ecx), %ebp #69.49
139 shufps $0, %xmm2, %xmm5 #60.21
140 movl 100(%esp), %ebx #69.20
141 movl (%ebx), %edi #69.20
142 imull %ebp, %edi #69.49
143 addl (%eax), %edi #70.33
144 shufps $85, %xmm2, %xmm4 #61.21
145 shufps $170, %xmm2, %xmm3 #62.21
146 shufps $255, %xmm2, %xmm2 #63.21
147 lea (%ebp,%ebp,2), %ebx #69.49
149 lea -3(%edi,%ebx), %ebx #70.33
151 addl 32(%ecx), %ebx #68.37
152 testb $15, %bl #91.13
153 jne L_B1.24 # Prob 5% #91.13
155 This is the llvm code after instruction scheduling:
157 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
158 %reg1078 = MOV32ri -3
159 %reg1079 = ADD32rm %reg1078, %reg1068, 1, %NOREG, 0
160 %reg1037 = MOV32rm %reg1024, 1, %NOREG, 40
161 %reg1080 = IMUL32rr %reg1079, %reg1037
162 %reg1081 = MOV32rm %reg1058, 1, %NOREG, 0
163 %reg1038 = LEA32r %reg1081, 1, %reg1080, -3
164 %reg1036 = MOV32rm %reg1024, 1, %NOREG, 32
165 %reg1082 = SHL32ri %reg1038, 4
166 %reg1039 = ADD32rr %reg1036, %reg1082
167 %reg1083 = MOVAPSrm %reg1059, 1, %NOREG, 0
168 %reg1034 = SHUFPSrr %reg1083, %reg1083, 170
169 %reg1032 = SHUFPSrr %reg1083, %reg1083, 0
170 %reg1035 = SHUFPSrr %reg1083, %reg1083, 255
171 %reg1033 = SHUFPSrr %reg1083, %reg1083, 85
172 %reg1040 = MOV32rr %reg1039
173 %reg1084 = AND32ri8 %reg1039, 15
175 JE mbb<cond_next204,0xa914d30>
177 Still ok. After register allocation:
179 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
181 %EDX = MOV32rm <fi#3>, 1, %NOREG, 0
182 ADD32rm %EAX<def&use>, %EDX, 1, %NOREG, 0
183 %EDX = MOV32rm <fi#7>, 1, %NOREG, 0
184 %EDX = MOV32rm %EDX, 1, %NOREG, 40
185 IMUL32rr %EAX<def&use>, %EDX
186 %ESI = MOV32rm <fi#5>, 1, %NOREG, 0
187 %ESI = MOV32rm %ESI, 1, %NOREG, 0
188 MOV32mr <fi#4>, 1, %NOREG, 0, %ESI
189 %EAX = LEA32r %ESI, 1, %EAX, -3
190 %ESI = MOV32rm <fi#7>, 1, %NOREG, 0
191 %ESI = MOV32rm %ESI, 1, %NOREG, 32
193 SHL32ri %EDI<def&use>, 4
194 ADD32rr %EDI<def&use>, %ESI
195 %XMM0 = MOVAPSrm %ECX, 1, %NOREG, 0
196 %XMM1 = MOVAPSrr %XMM0
197 SHUFPSrr %XMM1<def&use>, %XMM1, 170
198 %XMM2 = MOVAPSrr %XMM0
199 SHUFPSrr %XMM2<def&use>, %XMM2, 0
200 %XMM3 = MOVAPSrr %XMM0
201 SHUFPSrr %XMM3<def&use>, %XMM3, 255
202 SHUFPSrr %XMM0<def&use>, %XMM0, 85
204 AND32ri8 %EBX<def&use>, 15
206 JE mbb<cond_next204,0xa914d30>
208 This looks really bad. The problem is shufps is a destructive opcode. Since it
209 appears as operand two in more than one shufps ops. It resulted in a number of
210 copies. Note icc also suffers from the same problem. Either the instruction
211 selector should select pshufd or The register allocator can made the two-address
212 to three-address transformation.
214 It also exposes some other problems. See MOV32ri -3 and the spills.
216 //===---------------------------------------------------------------------===//
220 __m128 test(float a) {
221 return _mm_set_ps(0.0, 0.0, 0.0, a*a);
232 Because mulss doesn't modify the top 3 elements, the top elements of
233 xmm1 are already zero'd. We could compile this to:
239 //===---------------------------------------------------------------------===//
241 Here's a sick and twisted idea. Consider code like this:
243 __m128 test(__m128 a) {
244 float b = *(float*)&A;
246 return _mm_set_ps(0.0, 0.0, 0.0, b);
249 This might compile to this code:
251 movaps c(%esp), %xmm1
256 Now consider if the ... code caused xmm1 to get spilled. This might produce
259 movaps c(%esp), %xmm1
260 movaps %xmm1, c2(%esp)
264 movaps c2(%esp), %xmm1
268 However, since the reload is only used by these instructions, we could
269 "fold" it into the uses, producing something like this:
271 movaps c(%esp), %xmm1
272 movaps %xmm1, c2(%esp)
275 movss c2(%esp), %xmm0
278 ... saving two instructions.
280 The basic idea is that a reload from a spill slot, can, if only one 4-byte
281 chunk is used, bring in 3 zeros the one element instead of 4 elements.
282 This can be used to simplify a variety of shuffle operations, where the
283 elements are fixed zeros.
285 //===---------------------------------------------------------------------===//
287 This code generates ugly code, probably due to costs being off or something:
289 define void @test(float* %P, <4 x float>* %P2 ) {
290 %xFloat0.688 = load float* %P
291 %tmp = load <4 x float>* %P2
292 %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3
293 store <4 x float> %inFloat3.713, <4 x float>* %P2
304 shufps $50, %xmm1, %xmm2
305 shufps $132, %xmm2, %xmm0
309 Would it be better to generate:
315 pinsrw $6, %eax, %xmm0
316 pinsrw $7, %eax, %xmm0
322 //===---------------------------------------------------------------------===//
324 Some useful information in the Apple Altivec / SSE Migration Guide:
326 http://developer.apple.com/documentation/Performance/Conceptual/
327 Accelerate_sse_migration/index.html
329 e.g. SSE select using and, andnot, or. Various SSE compare translations.
331 //===---------------------------------------------------------------------===//
333 Add hooks to commute some CMPP operations.
335 //===---------------------------------------------------------------------===//
337 Apply the same transformation that merged four float into a single 128-bit load
338 to loads from constant pool.
340 //===---------------------------------------------------------------------===//
342 Floating point max / min are commutable when -enable-unsafe-fp-path is
343 specified. We should turn int_x86_sse_max_ss and X86ISD::FMIN etc. into other
344 nodes which are selected to max / min instructions that are marked commutable.
346 //===---------------------------------------------------------------------===//
348 We should materialize vector constants like "all ones" and "signbit" with
351 cmpeqps xmm1, xmm1 ; xmm1 = all-ones
354 cmpeqps xmm1, xmm1 ; xmm1 = all-ones
355 psrlq xmm1, 31 ; xmm1 = all 100000000000...
357 instead of using a load from the constant pool. The later is important for
358 ABS/NEG/copysign etc.
360 //===---------------------------------------------------------------------===//
364 #include <xmmintrin.h>
366 void x(unsigned short n) {
367 a = _mm_slli_epi32 (a, n);
370 a = _mm_slli_epi32 (a, n);
373 compile to ( -O3 -static -fomit-frame-pointer):
388 "y" looks good, but "x" does silly movzwl stuff around into a GPR. It seems
389 like movd would be sufficient in both cases as the value is already zero
390 extended in the 32-bit stack slot IIRC. For signed short, it should also be
391 save, as a really-signed value would be undefined for pslld.
394 //===---------------------------------------------------------------------===//
397 int t1(double d) { return signbit(d); }
399 This currently compiles to:
401 movsd 16(%esp), %xmm0
408 We should use movmskp{s|d} instead.
410 //===---------------------------------------------------------------------===//
412 CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
413 (aligned) vector load. This functionality has a couple of problems.
415 1. The code to infer alignment from loads of globals is in the X86 backend,
416 not the dag combiner. This is because dagcombine2 needs to be able to see
417 through the X86ISD::Wrapper node, which DAGCombine can't really do.
418 2. The code for turning 4 x load into a single vector load is target
419 independent and should be moved to the dag combiner.
420 3. The code for turning 4 x load into a vector load can only handle a direct
421 load from a global or a direct load from the stack. It should be generalized
422 to handle any load from P, P+4, P+8, P+12, where P can be anything.
423 4. The alignment inference code cannot handle loads from globals in non-static
424 mode because it doesn't look through the extra dyld stub load. If you try
425 vec_align.ll without -relocation-model=static, you'll see what I mean.
427 //===---------------------------------------------------------------------===//
429 We should lower store(fneg(load p), q) into an integer load+xor+store, which
430 eliminates a constant pool load. For example, consider:
432 define i64 @ccosf(float %z.0, float %z.1) nounwind readonly {
434 %tmp6 = fsub float -0.000000e+00, %z.1 ; <float> [#uses=1]
435 %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly
438 declare i64 @ccoshf(float %z.0, float %z.1) nounwind readonly
440 This currently compiles to:
442 LCPI1_0: # <4 x float>
443 .long 2147483648 # float -0
444 .long 2147483648 # float -0
445 .long 2147483648 # float -0
446 .long 2147483648 # float -0
449 movss 16(%esp), %xmm0
451 movss 20(%esp), %xmm0
458 Note the load into xmm0, then xor (to negate), then store. In PIC mode,
459 this code computes the pic base and does two loads to do the constant pool
460 load, so the improvement is much bigger.
462 The tricky part about this xform is that the argument load/store isn't exposed
463 until post-legalize, and at that point, the fneg has been custom expanded into
464 an X86 fxor. This means that we need to handle this case in the x86 backend
465 instead of in target independent code.
467 //===---------------------------------------------------------------------===//
469 Non-SSE4 insert into 16 x i8 is atrociously bad.
471 //===---------------------------------------------------------------------===//
473 <2 x i64> extract is substantially worse than <2 x f64>, even if the destination
476 //===---------------------------------------------------------------------===//
478 SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
479 sitting between the truncate and the extract.
481 //===---------------------------------------------------------------------===//
483 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
484 any number of 0.0 simultaneously. Currently we only use it for simple
487 See comments in LowerINSERT_VECTOR_ELT_SSE4.
489 //===---------------------------------------------------------------------===//
491 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
492 Custom. All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
493 legal, it'll just take a few extra patterns written in the .td file.
495 Note: this is not a code quality issue; the custom lowered code happens to be
496 right, but we shouldn't have to custom lower anything. This is probably related
497 to <2 x i64> ops being so bad.
499 //===---------------------------------------------------------------------===//
501 'select' on vectors and scalars could be a whole lot better. We currently
502 lower them to conditional branches. On x86-64 for example, we compile this:
504 double test(double a, double b, double c, double d) { return a<b ? c : d; }
526 For unpredictable branches, the later is much more efficient. This should
527 just be a matter of having scalar sse map to SELECT_CC and custom expanding
530 //===---------------------------------------------------------------------===//
532 LLVM currently generates stack realignment code, when it is not necessary
533 needed. The problem is that we need to know about stack alignment too early,
536 At that point we don't know, whether there will be vector spill, or not.
537 Stack realignment logic is overly conservative here, but otherwise we can
538 produce unaligned loads/stores.
540 Fixing this will require some huge RA changes.
543 #include <emmintrin.h>
545 typedef short vSInt16 __attribute__ ((__vector_size__ (16)));
547 static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,
550 vSInt16 madd(vSInt16 b)
552 return _mm_madd_epi16(a, b);
555 Generated code (x86-32, linux):
560 movaps .LCPI1_0, %xmm1
566 //===---------------------------------------------------------------------===//
569 #include <emmintrin.h>
570 __m128 foo2 (float x) {
571 return _mm_set_ps (0, 0, x, 0);
574 In x86-32 mode, we generate this spiffy code:
578 pshufd $81, %xmm0, %xmm0
581 in x86-64 mode, we generate this code, which could be better:
586 pshufd $81, %xmm1, %xmm0
589 In sse4 mode, we could use insertps to make both better.
591 Here's another testcase that could use insertps [mem]:
593 #include <xmmintrin.h>
595 __m128 foo1 (float x1, float x4) {
596 return _mm_set_ps (x2, x1, x3, x4);
599 gcc mainline compiles it to:
602 insertps $0x10, x2(%rip), %xmm0
603 insertps $0x10, x3(%rip), %xmm1
609 //===---------------------------------------------------------------------===//
611 We compile vector multiply-by-constant into poor code:
613 define <4 x i32> @f(<4 x i32> %i) nounwind {
614 %A = mul <4 x i32> %i, < i32 10, i32 10, i32 10, i32 10 >
618 On targets without SSE4.1, this compiles into:
620 LCPI1_0: ## <4 x i32>
629 pshufd $3, %xmm0, %xmm1
631 imull LCPI1_0+12, %eax
633 pshufd $1, %xmm0, %xmm2
635 imull LCPI1_0+4, %eax
637 punpckldq %xmm1, %xmm2
643 imull LCPI1_0+8, %eax
645 punpckldq %xmm0, %xmm1
647 punpckldq %xmm2, %xmm0
650 It would be better to synthesize integer vector multiplication by constants
651 using shifts and adds, pslld and paddd here. And even on targets with SSE4.1,
652 simple cases such as multiplication by powers of two would be better as
653 vector shifts than as multiplications.
655 //===---------------------------------------------------------------------===//
662 return _mm_set_epi8 (1, 0, 0, 0, 0, 0, 0, 0, 0, x, 0, 1, 0, 0, 0, 0);
668 pinsrw $2, %eax, %xmm0
670 pinsrw $3, %eax, %xmm0
672 pinsrw $7, %eax, %xmm0
678 movzbl 16(%esp), %eax
680 pinsrw $3, %eax, %xmm0
695 With SSE4, it should be
696 movdqa .LC0(%rip), %xmm0
697 pinsrb $6, %edi, %xmm0
699 //===---------------------------------------------------------------------===//
701 We should transform a shuffle of two vectors of constants into a single vector
702 of constants. Also, insertelement of a constant into a vector of constants
703 should also result in a vector of constants. e.g. 2008-06-25-VecISelBug.ll.
705 We compiled it to something horrible:
709 .long 1065353216 ## float 1
713 LCPI1_0: ## <4 x float>
715 .long 1065353216 ## float 1
717 .long 1065353216 ## float 1
723 movhps LCPI1_0, %xmm0
726 shufps $2, %xmm1, %xmm2
727 shufps $132, %xmm2, %xmm0
730 //===---------------------------------------------------------------------===//
735 float foo(unsigned char x) {
739 compiles to (x86-32):
741 define float @foo(i8 zeroext %x) nounwind {
742 %tmp12 = uitofp i8 %x to float ; <float> [#uses=1]
757 We should be able to use:
758 cvtsi2ss 8($esp), %xmm0
759 since we know the stack slot is already zext'd.
761 //===---------------------------------------------------------------------===//
763 Consider using movlps instead of movsd to implement (scalar_to_vector (loadf64))
764 when code size is critical. movlps is slower than movsd on core2 but it's one
767 //===---------------------------------------------------------------------===//
769 We should use a dynamic programming based approach to tell when using FPStack
770 operations is cheaper than SSE. SciMark montecarlo contains code like this
773 double MonteCarlo_num_flops(int Num_samples) {
774 return ((double) Num_samples)* 4.0;
777 In fpstack mode, this compiles into:
780 .long 1082130432 ## float 4.000000e+00
781 _MonteCarlo_num_flops:
790 in SSE mode, it compiles into significantly slower code:
792 _MonteCarlo_num_flops:
794 cvtsi2sd 16(%esp), %xmm0
801 There are also other cases in scimark where using fpstack is better, it is
802 cheaper to do fld1 than load from a constant pool for example, so
803 "load, add 1.0, store" is better done in the fp stack, etc.
805 //===---------------------------------------------------------------------===//
807 The X86 backend should be able to if-convert SSE comparisons like "ucomisd" to
808 "cmpsd". For example, this code:
810 double d1(double x) { return x == x ? x : x + x; }
822 Also, the 'ret's should be shared. This is PR6032.
824 //===---------------------------------------------------------------------===//
826 These should compile into the same code (PR6214): Perhaps instcombine should
827 canonicalize the former into the later?
829 define float @foo(float %x) nounwind {
830 %t = bitcast float %x to i32
831 %s = and i32 %t, 2147483647
832 %d = bitcast i32 %s to float
836 declare float @fabsf(float %n)
837 define float @bar(float %x) nounwind {
838 %d = call float @fabsf(float %x)
842 //===---------------------------------------------------------------------===//
844 This IR (from PR6194):
846 target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
847 target triple = "x86_64-apple-darwin10.0.0"
849 %0 = type { double, double }
850 %struct.float3 = type { float, float, float }
852 define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp {
854 %tmp18 = extractvalue %0 %0, 0 ; <double> [#uses=1]
855 %tmp19 = bitcast double %tmp18 to i64 ; <i64> [#uses=1]
856 %tmp20 = zext i64 %tmp19 to i128 ; <i128> [#uses=1]
857 %tmp10 = lshr i128 %tmp20, 32 ; <i128> [#uses=1]
858 %tmp11 = trunc i128 %tmp10 to i32 ; <i32> [#uses=1]
859 %tmp12 = bitcast i32 %tmp11 to float ; <float> [#uses=1]
860 %tmp5 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ; <float*> [#uses=1]
861 store float %tmp12, float* %tmp5
873 This would be better kept in the SSE unit by treating XMM0 as a 4xfloat and
874 doing a shuffle from v[1] to v[0] then a float store.
876 //===---------------------------------------------------------------------===//
878 On SSE4 machines, we compile this code:
880 define <2 x float> @test2(<2 x float> %Q, <2 x float> %R,
881 <2 x float> *%P) nounwind {
882 %Z = fadd <2 x float> %Q, %R
884 store <2 x float> %Z, <2 x float> *%P
892 insertps $0, %xmm2, %xmm2
893 insertps $16, %xmm3, %xmm2
894 insertps $0, %xmm0, %xmm3
895 insertps $16, %xmm1, %xmm3
899 pshufd $1, %xmm3, %xmm1
900 ## kill: XMM1<def> XMM1<kill>
903 The insertps's of $0 are pointless complex copies.
905 //===---------------------------------------------------------------------===//