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 Expand libm rounding functions inline: Significant speedups possible.
23 http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00909.html
25 //===---------------------------------------------------------------------===//
27 When compiled with unsafemath enabled, "main" should enable SSE DAZ mode and
30 //===---------------------------------------------------------------------===//
32 Think about doing i64 math in SSE regs on x86-32.
34 //===---------------------------------------------------------------------===//
36 This testcase should have no SSE instructions in it, and only one load from
39 double %test3(bool %B) {
40 %C = select bool %B, double 123.412, double 523.01123123
44 Currently, the select is being lowered, which prevents the dag combiner from
45 turning 'select (load CPI1), (load CPI2)' -> 'load (select CPI1, CPI2)'
47 The pattern isel got this one right.
49 //===---------------------------------------------------------------------===//
51 SSE should implement 'select_cc' using 'emulated conditional moves' that use
52 pcmp/pand/pandn/por to do a selection instead of a conditional branch:
54 double %X(double %Y, double %Z, double %A, double %B) {
55 %C = setlt double %A, %B
56 %z = fadd double %Z, 0.0 ;; select operand is not a load
57 %D = select bool %C, double %Y, double %z
69 ucomisd 40(%esp), %xmm1
79 //===---------------------------------------------------------------------===//
81 Lower memcpy / memset to a series of SSE 128 bit move instructions when it's
84 //===---------------------------------------------------------------------===//
87 if (copysign(1.0, x) == copysign(1.0, y))
92 //===---------------------------------------------------------------------===//
94 Use movhps to update upper 64-bits of a v4sf value. Also movlps on lower half
97 //===---------------------------------------------------------------------===//
99 Better codegen for vector_shuffles like this { x, 0, 0, 0 } or { x, 0, x, 0}.
100 Perhaps use pxor / xorp* to clear a XMM register first?
102 //===---------------------------------------------------------------------===//
104 External test Nurbs exposed some problems. Look for
105 __ZN15Nurbs_SSE_Cubic17TessellateSurfaceE, bb cond_next140. This is what icc
108 movaps (%edx), %xmm2 #59.21
109 movaps (%edx), %xmm5 #60.21
110 movaps (%edx), %xmm4 #61.21
111 movaps (%edx), %xmm3 #62.21
112 movl 40(%ecx), %ebp #69.49
113 shufps $0, %xmm2, %xmm5 #60.21
114 movl 100(%esp), %ebx #69.20
115 movl (%ebx), %edi #69.20
116 imull %ebp, %edi #69.49
117 addl (%eax), %edi #70.33
118 shufps $85, %xmm2, %xmm4 #61.21
119 shufps $170, %xmm2, %xmm3 #62.21
120 shufps $255, %xmm2, %xmm2 #63.21
121 lea (%ebp,%ebp,2), %ebx #69.49
123 lea -3(%edi,%ebx), %ebx #70.33
125 addl 32(%ecx), %ebx #68.37
126 testb $15, %bl #91.13
127 jne L_B1.24 # Prob 5% #91.13
129 This is the llvm code after instruction scheduling:
131 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
132 %reg1078 = MOV32ri -3
133 %reg1079 = ADD32rm %reg1078, %reg1068, 1, %NOREG, 0
134 %reg1037 = MOV32rm %reg1024, 1, %NOREG, 40
135 %reg1080 = IMUL32rr %reg1079, %reg1037
136 %reg1081 = MOV32rm %reg1058, 1, %NOREG, 0
137 %reg1038 = LEA32r %reg1081, 1, %reg1080, -3
138 %reg1036 = MOV32rm %reg1024, 1, %NOREG, 32
139 %reg1082 = SHL32ri %reg1038, 4
140 %reg1039 = ADD32rr %reg1036, %reg1082
141 %reg1083 = MOVAPSrm %reg1059, 1, %NOREG, 0
142 %reg1034 = SHUFPSrr %reg1083, %reg1083, 170
143 %reg1032 = SHUFPSrr %reg1083, %reg1083, 0
144 %reg1035 = SHUFPSrr %reg1083, %reg1083, 255
145 %reg1033 = SHUFPSrr %reg1083, %reg1083, 85
146 %reg1040 = MOV32rr %reg1039
147 %reg1084 = AND32ri8 %reg1039, 15
149 JE mbb<cond_next204,0xa914d30>
151 Still ok. After register allocation:
153 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
155 %EDX = MOV32rm <fi#3>, 1, %NOREG, 0
156 ADD32rm %EAX<def&use>, %EDX, 1, %NOREG, 0
157 %EDX = MOV32rm <fi#7>, 1, %NOREG, 0
158 %EDX = MOV32rm %EDX, 1, %NOREG, 40
159 IMUL32rr %EAX<def&use>, %EDX
160 %ESI = MOV32rm <fi#5>, 1, %NOREG, 0
161 %ESI = MOV32rm %ESI, 1, %NOREG, 0
162 MOV32mr <fi#4>, 1, %NOREG, 0, %ESI
163 %EAX = LEA32r %ESI, 1, %EAX, -3
164 %ESI = MOV32rm <fi#7>, 1, %NOREG, 0
165 %ESI = MOV32rm %ESI, 1, %NOREG, 32
167 SHL32ri %EDI<def&use>, 4
168 ADD32rr %EDI<def&use>, %ESI
169 %XMM0 = MOVAPSrm %ECX, 1, %NOREG, 0
170 %XMM1 = MOVAPSrr %XMM0
171 SHUFPSrr %XMM1<def&use>, %XMM1, 170
172 %XMM2 = MOVAPSrr %XMM0
173 SHUFPSrr %XMM2<def&use>, %XMM2, 0
174 %XMM3 = MOVAPSrr %XMM0
175 SHUFPSrr %XMM3<def&use>, %XMM3, 255
176 SHUFPSrr %XMM0<def&use>, %XMM0, 85
178 AND32ri8 %EBX<def&use>, 15
180 JE mbb<cond_next204,0xa914d30>
182 This looks really bad. The problem is shufps is a destructive opcode. Since it
183 appears as operand two in more than one shufps ops. It resulted in a number of
184 copies. Note icc also suffers from the same problem. Either the instruction
185 selector should select pshufd or The register allocator can made the two-address
186 to three-address transformation.
188 It also exposes some other problems. See MOV32ri -3 and the spills.
190 //===---------------------------------------------------------------------===//
194 __m128 test(float a) {
195 return _mm_set_ps(0.0, 0.0, 0.0, a*a);
206 Because mulss doesn't modify the top 3 elements, the top elements of
207 xmm1 are already zero'd. We could compile this to:
213 //===---------------------------------------------------------------------===//
215 Here's a sick and twisted idea. Consider code like this:
217 __m128 test(__m128 a) {
218 float b = *(float*)&A;
220 return _mm_set_ps(0.0, 0.0, 0.0, b);
223 This might compile to this code:
225 movaps c(%esp), %xmm1
230 Now consider if the ... code caused xmm1 to get spilled. This might produce
233 movaps c(%esp), %xmm1
234 movaps %xmm1, c2(%esp)
238 movaps c2(%esp), %xmm1
242 However, since the reload is only used by these instructions, we could
243 "fold" it into the uses, producing something like this:
245 movaps c(%esp), %xmm1
246 movaps %xmm1, c2(%esp)
249 movss c2(%esp), %xmm0
252 ... saving two instructions.
254 The basic idea is that a reload from a spill slot, can, if only one 4-byte
255 chunk is used, bring in 3 zeros the one element instead of 4 elements.
256 This can be used to simplify a variety of shuffle operations, where the
257 elements are fixed zeros.
259 //===---------------------------------------------------------------------===//
261 This code generates ugly code, probably due to costs being off or something:
263 define void @test(float* %P, <4 x float>* %P2 ) {
264 %xFloat0.688 = load float* %P
265 %tmp = load <4 x float>* %P2
266 %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3
267 store <4 x float> %inFloat3.713, <4 x float>* %P2
278 shufps $50, %xmm1, %xmm2
279 shufps $132, %xmm2, %xmm0
283 Would it be better to generate:
289 pinsrw $6, %eax, %xmm0
290 pinsrw $7, %eax, %xmm0
296 //===---------------------------------------------------------------------===//
298 Some useful information in the Apple Altivec / SSE Migration Guide:
300 http://developer.apple.com/documentation/Performance/Conceptual/
301 Accelerate_sse_migration/index.html
303 e.g. SSE select using and, andnot, or. Various SSE compare translations.
305 //===---------------------------------------------------------------------===//
307 Add hooks to commute some CMPP operations.
309 //===---------------------------------------------------------------------===//
311 Apply the same transformation that merged four float into a single 128-bit load
312 to loads from constant pool.
314 //===---------------------------------------------------------------------===//
316 Floating point max / min are commutable when -enable-unsafe-fp-path is
317 specified. We should turn int_x86_sse_max_ss and X86ISD::FMIN etc. into other
318 nodes which are selected to max / min instructions that are marked commutable.
320 //===---------------------------------------------------------------------===//
322 We should materialize vector constants like "all ones" and "signbit" with
325 cmpeqps xmm1, xmm1 ; xmm1 = all-ones
328 cmpeqps xmm1, xmm1 ; xmm1 = all-ones
329 psrlq xmm1, 31 ; xmm1 = all 100000000000...
331 instead of using a load from the constant pool. The later is important for
332 ABS/NEG/copysign etc.
334 //===---------------------------------------------------------------------===//
338 #include <xmmintrin.h>
340 void x(unsigned short n) {
341 a = _mm_slli_epi32 (a, n);
344 a = _mm_slli_epi32 (a, n);
347 compile to ( -O3 -static -fomit-frame-pointer):
362 "y" looks good, but "x" does silly movzwl stuff around into a GPR. It seems
363 like movd would be sufficient in both cases as the value is already zero
364 extended in the 32-bit stack slot IIRC. For signed short, it should also be
365 save, as a really-signed value would be undefined for pslld.
368 //===---------------------------------------------------------------------===//
371 int t1(double d) { return signbit(d); }
373 This currently compiles to:
375 movsd 16(%esp), %xmm0
382 We should use movmskp{s|d} instead.
384 //===---------------------------------------------------------------------===//
386 CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
387 (aligned) vector load. This functionality has a couple of problems.
389 1. The code to infer alignment from loads of globals is in the X86 backend,
390 not the dag combiner. This is because dagcombine2 needs to be able to see
391 through the X86ISD::Wrapper node, which DAGCombine can't really do.
392 2. The code for turning 4 x load into a single vector load is target
393 independent and should be moved to the dag combiner.
394 3. The code for turning 4 x load into a vector load can only handle a direct
395 load from a global or a direct load from the stack. It should be generalized
396 to handle any load from P, P+4, P+8, P+12, where P can be anything.
397 4. The alignment inference code cannot handle loads from globals in non-static
398 mode because it doesn't look through the extra dyld stub load. If you try
399 vec_align.ll without -relocation-model=static, you'll see what I mean.
401 //===---------------------------------------------------------------------===//
403 We should lower store(fneg(load p), q) into an integer load+xor+store, which
404 eliminates a constant pool load. For example, consider:
406 define i64 @ccosf(float %z.0, float %z.1) nounwind readonly {
408 %tmp6 = fsub float -0.000000e+00, %z.1 ; <float> [#uses=1]
409 %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly
412 declare i64 @ccoshf(float %z.0, float %z.1) nounwind readonly
414 This currently compiles to:
416 LCPI1_0: # <4 x float>
417 .long 2147483648 # float -0
418 .long 2147483648 # float -0
419 .long 2147483648 # float -0
420 .long 2147483648 # float -0
423 movss 16(%esp), %xmm0
425 movss 20(%esp), %xmm0
432 Note the load into xmm0, then xor (to negate), then store. In PIC mode,
433 this code computes the pic base and does two loads to do the constant pool
434 load, so the improvement is much bigger.
436 The tricky part about this xform is that the argument load/store isn't exposed
437 until post-legalize, and at that point, the fneg has been custom expanded into
438 an X86 fxor. This means that we need to handle this case in the x86 backend
439 instead of in target independent code.
441 //===---------------------------------------------------------------------===//
443 Non-SSE4 insert into 16 x i8 is atrociously bad.
445 //===---------------------------------------------------------------------===//
447 <2 x i64> extract is substantially worse than <2 x f64>, even if the destination
450 //===---------------------------------------------------------------------===//
452 SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
453 sitting between the truncate and the extract.
455 //===---------------------------------------------------------------------===//
457 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
458 any number of 0.0 simultaneously. Currently we only use it for simple
461 See comments in LowerINSERT_VECTOR_ELT_SSE4.
463 //===---------------------------------------------------------------------===//
465 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
466 Custom. All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
467 legal, it'll just take a few extra patterns written in the .td file.
469 Note: this is not a code quality issue; the custom lowered code happens to be
470 right, but we shouldn't have to custom lower anything. This is probably related
471 to <2 x i64> ops being so bad.
473 //===---------------------------------------------------------------------===//
475 'select' on vectors and scalars could be a whole lot better. We currently
476 lower them to conditional branches. On x86-64 for example, we compile this:
478 double test(double a, double b, double c, double d) { return a<b ? c : d; }
500 For unpredictable branches, the later is much more efficient. This should
501 just be a matter of having scalar sse map to SELECT_CC and custom expanding
504 //===---------------------------------------------------------------------===//
506 LLVM currently generates stack realignment code, when it is not necessary
507 needed. The problem is that we need to know about stack alignment too early,
510 At that point we don't know, whether there will be vector spill, or not.
511 Stack realignment logic is overly conservative here, but otherwise we can
512 produce unaligned loads/stores.
514 Fixing this will require some huge RA changes.
517 #include <emmintrin.h>
519 typedef short vSInt16 __attribute__ ((__vector_size__ (16)));
521 static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,
524 vSInt16 madd(vSInt16 b)
526 return _mm_madd_epi16(a, b);
529 Generated code (x86-32, linux):
534 movaps .LCPI1_0, %xmm1
540 //===---------------------------------------------------------------------===//
543 #include <emmintrin.h>
544 __m128 foo2 (float x) {
545 return _mm_set_ps (0, 0, x, 0);
548 In x86-32 mode, we generate this spiffy code:
552 pshufd $81, %xmm0, %xmm0
555 in x86-64 mode, we generate this code, which could be better:
560 pshufd $81, %xmm1, %xmm0
563 In sse4 mode, we could use insertps to make both better.
565 Here's another testcase that could use insertps [mem]:
567 #include <xmmintrin.h>
569 __m128 foo1 (float x1, float x4) {
570 return _mm_set_ps (x2, x1, x3, x4);
573 gcc mainline compiles it to:
576 insertps $0x10, x2(%rip), %xmm0
577 insertps $0x10, x3(%rip), %xmm1
583 //===---------------------------------------------------------------------===//
585 We compile vector multiply-by-constant into poor code:
587 define <4 x i32> @f(<4 x i32> %i) nounwind {
588 %A = mul <4 x i32> %i, < i32 10, i32 10, i32 10, i32 10 >
592 On targets without SSE4.1, this compiles into:
594 LCPI1_0: ## <4 x i32>
603 pshufd $3, %xmm0, %xmm1
605 imull LCPI1_0+12, %eax
607 pshufd $1, %xmm0, %xmm2
609 imull LCPI1_0+4, %eax
611 punpckldq %xmm1, %xmm2
617 imull LCPI1_0+8, %eax
619 punpckldq %xmm0, %xmm1
621 punpckldq %xmm2, %xmm0
624 It would be better to synthesize integer vector multiplication by constants
625 using shifts and adds, pslld and paddd here. And even on targets with SSE4.1,
626 simple cases such as multiplication by powers of two would be better as
627 vector shifts than as multiplications.
629 //===---------------------------------------------------------------------===//
636 return _mm_set_epi8 (1, 0, 0, 0, 0, 0, 0, 0, 0, x, 0, 1, 0, 0, 0, 0);
642 pinsrw $2, %eax, %xmm0
644 pinsrw $3, %eax, %xmm0
646 pinsrw $7, %eax, %xmm0
652 movzbl 16(%esp), %eax
654 pinsrw $3, %eax, %xmm0
669 With SSE4, it should be
670 movdqa .LC0(%rip), %xmm0
671 pinsrb $6, %edi, %xmm0
673 //===---------------------------------------------------------------------===//
675 We should transform a shuffle of two vectors of constants into a single vector
676 of constants. Also, insertelement of a constant into a vector of constants
677 should also result in a vector of constants. e.g. 2008-06-25-VecISelBug.ll.
679 We compiled it to something horrible:
683 .long 1065353216 ## float 1
687 LCPI1_0: ## <4 x float>
689 .long 1065353216 ## float 1
691 .long 1065353216 ## float 1
697 movhps LCPI1_0, %xmm0
700 shufps $2, %xmm1, %xmm2
701 shufps $132, %xmm2, %xmm0
704 //===---------------------------------------------------------------------===//
709 float foo(unsigned char x) {
713 compiles to (x86-32):
715 define float @foo(i8 zeroext %x) nounwind {
716 %tmp12 = uitofp i8 %x to float ; <float> [#uses=1]
731 We should be able to use:
732 cvtsi2ss 8($esp), %xmm0
733 since we know the stack slot is already zext'd.
735 //===---------------------------------------------------------------------===//
737 Consider using movlps instead of movsd to implement (scalar_to_vector (loadf64))
738 when code size is critical. movlps is slower than movsd on core2 but it's one
741 //===---------------------------------------------------------------------===//
743 We should use a dynamic programming based approach to tell when using FPStack
744 operations is cheaper than SSE. SciMark montecarlo contains code like this
747 double MonteCarlo_num_flops(int Num_samples) {
748 return ((double) Num_samples)* 4.0;
751 In fpstack mode, this compiles into:
754 .long 1082130432 ## float 4.000000e+00
755 _MonteCarlo_num_flops:
764 in SSE mode, it compiles into significantly slower code:
766 _MonteCarlo_num_flops:
768 cvtsi2sd 16(%esp), %xmm0
775 There are also other cases in scimark where using fpstack is better, it is
776 cheaper to do fld1 than load from a constant pool for example, so
777 "load, add 1.0, store" is better done in the fp stack, etc.
779 //===---------------------------------------------------------------------===//
781 The X86 backend should be able to if-convert SSE comparisons like "ucomisd" to
782 "cmpsd". For example, this code:
784 double d1(double x) { return x == x ? x : x + x; }
796 Also, the 'ret's should be shared. This is PR6032.
798 //===---------------------------------------------------------------------===//
800 These should compile into the same code (PR6214): Perhaps instcombine should
801 canonicalize the former into the later?
803 define float @foo(float %x) nounwind {
804 %t = bitcast float %x to i32
805 %s = and i32 %t, 2147483647
806 %d = bitcast i32 %s to float
810 declare float @fabsf(float %n)
811 define float @bar(float %x) nounwind {
812 %d = call float @fabsf(float %x)
816 //===---------------------------------------------------------------------===//
818 This IR (from PR6194):
820 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"
821 target triple = "x86_64-apple-darwin10.0.0"
823 %0 = type { double, double }
824 %struct.float3 = type { float, float, float }
826 define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp {
828 %tmp18 = extractvalue %0 %0, 0 ; <double> [#uses=1]
829 %tmp19 = bitcast double %tmp18 to i64 ; <i64> [#uses=1]
830 %tmp20 = zext i64 %tmp19 to i128 ; <i128> [#uses=1]
831 %tmp10 = lshr i128 %tmp20, 32 ; <i128> [#uses=1]
832 %tmp11 = trunc i128 %tmp10 to i32 ; <i32> [#uses=1]
833 %tmp12 = bitcast i32 %tmp11 to float ; <float> [#uses=1]
834 %tmp5 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ; <float*> [#uses=1]
835 store float %tmp12, float* %tmp5
847 This would be better kept in the SSE unit by treating XMM0 as a 4xfloat and
848 doing a shuffle from v[1] to v[0] then a float store.
850 //===---------------------------------------------------------------------===//
852 On SSE4 machines, we compile this code:
854 define <2 x float> @test2(<2 x float> %Q, <2 x float> %R,
855 <2 x float> *%P) nounwind {
856 %Z = fadd <2 x float> %Q, %R
858 store <2 x float> %Z, <2 x float> *%P
866 insertps $0, %xmm2, %xmm2
867 insertps $16, %xmm3, %xmm2
868 insertps $0, %xmm0, %xmm3
869 insertps $16, %xmm1, %xmm3
873 pshufd $1, %xmm3, %xmm1
874 ## kill: XMM1<def> XMM1<kill>
877 The insertps's of $0 are pointless complex copies.
879 //===---------------------------------------------------------------------===//