| //===---------------------------------------------------------------------===// |
| // Random ideas for the X86 backend: SSE-specific stuff. |
| //===---------------------------------------------------------------------===// |
| |
| //===---------------------------------------------------------------------===// |
| |
| SSE Variable shift can be custom lowered to something like this, which uses a |
| small table + unaligned load + shuffle instead of going through memory. |
| |
| __m128i_shift_right: |
| .byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 |
| .byte -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 |
| |
| ... |
| __m128i shift_right(__m128i value, unsigned long offset) { |
| return _mm_shuffle_epi8(value, |
| _mm_loadu_si128((__m128 *) (___m128i_shift_right + offset))); |
| } |
| |
| //===---------------------------------------------------------------------===// |
| |
| SSE has instructions for doing operations on complex numbers, we should pattern |
| match them. For example, this should turn into a horizontal add: |
| |
| typedef float __attribute__((vector_size(16))) v4f32; |
| float f32(v4f32 A) { |
| return A[0]+A[1]+A[2]+A[3]; |
| } |
| |
| Instead we get this: |
| |
| _f32: ## @f32 |
| pshufd $1, %xmm0, %xmm1 ## xmm1 = xmm0[1,0,0,0] |
| addss %xmm0, %xmm1 |
| pshufd $3, %xmm0, %xmm2 ## xmm2 = xmm0[3,0,0,0] |
| movhlps %xmm0, %xmm0 ## xmm0 = xmm0[1,1] |
| movaps %xmm0, %xmm3 |
| addss %xmm1, %xmm3 |
| movdqa %xmm2, %xmm0 |
| addss %xmm3, %xmm0 |
| ret |
| |
| Also, there are cases where some simple local SLP would improve codegen a bit. |
| compiling this: |
| |
| _Complex float f32(_Complex float A, _Complex float B) { |
| return A+B; |
| } |
| |
| into: |
| |
| _f32: ## @f32 |
| movdqa %xmm0, %xmm2 |
| addss %xmm1, %xmm2 |
| pshufd $1, %xmm1, %xmm1 ## xmm1 = xmm1[1,0,0,0] |
| pshufd $1, %xmm0, %xmm3 ## xmm3 = xmm0[1,0,0,0] |
| addss %xmm1, %xmm3 |
| movaps %xmm2, %xmm0 |
| unpcklps %xmm3, %xmm0 ## xmm0 = xmm0[0],xmm3[0],xmm0[1],xmm3[1] |
| ret |
| |
| seems silly when it could just be one addps. |
| |
| |
| //===---------------------------------------------------------------------===// |
| |
| Expand libm rounding functions inline: Significant speedups possible. |
| http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00909.html |
| |
| //===---------------------------------------------------------------------===// |
| |
| When compiled with unsafemath enabled, "main" should enable SSE DAZ mode and |
| other fast SSE modes. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Think about doing i64 math in SSE regs on x86-32. |
| |
| //===---------------------------------------------------------------------===// |
| |
| This testcase should have no SSE instructions in it, and only one load from |
| a constant pool: |
| |
| double %test3(bool %B) { |
| %C = select bool %B, double 123.412, double 523.01123123 |
| ret double %C |
| } |
| |
| Currently, the select is being lowered, which prevents the dag combiner from |
| turning 'select (load CPI1), (load CPI2)' -> 'load (select CPI1, CPI2)' |
| |
| The pattern isel got this one right. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Lower memcpy / memset to a series of SSE 128 bit move instructions when it's |
| feasible. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Codegen: |
| if (copysign(1.0, x) == copysign(1.0, y)) |
| into: |
| if (x^y & mask) |
| when using SSE. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Use movhps to update upper 64-bits of a v4sf value. Also movlps on lower half |
| of a v4sf value. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Better codegen for vector_shuffles like this { x, 0, 0, 0 } or { x, 0, x, 0}. |
| Perhaps use pxor / xorp* to clear a XMM register first? |
| |
| //===---------------------------------------------------------------------===// |
| |
| External test Nurbs exposed some problems. Look for |
| __ZN15Nurbs_SSE_Cubic17TessellateSurfaceE, bb cond_next140. This is what icc |
| emits: |
| |
| movaps (%edx), %xmm2 #59.21 |
| movaps (%edx), %xmm5 #60.21 |
| movaps (%edx), %xmm4 #61.21 |
| movaps (%edx), %xmm3 #62.21 |
| movl 40(%ecx), %ebp #69.49 |
| shufps $0, %xmm2, %xmm5 #60.21 |
| movl 100(%esp), %ebx #69.20 |
| movl (%ebx), %edi #69.20 |
| imull %ebp, %edi #69.49 |
| addl (%eax), %edi #70.33 |
| shufps $85, %xmm2, %xmm4 #61.21 |
| shufps $170, %xmm2, %xmm3 #62.21 |
| shufps $255, %xmm2, %xmm2 #63.21 |
| lea (%ebp,%ebp,2), %ebx #69.49 |
| negl %ebx #69.49 |
| lea -3(%edi,%ebx), %ebx #70.33 |
| shll $4, %ebx #68.37 |
| addl 32(%ecx), %ebx #68.37 |
| testb $15, %bl #91.13 |
| jne L_B1.24 # Prob 5% #91.13 |
| |
| This is the llvm code after instruction scheduling: |
| |
| cond_next140 (0xa910740, LLVM BB @0xa90beb0): |
| %reg1078 = MOV32ri -3 |
| %reg1079 = ADD32rm %reg1078, %reg1068, 1, %noreg, 0 |
| %reg1037 = MOV32rm %reg1024, 1, %noreg, 40 |
| %reg1080 = IMUL32rr %reg1079, %reg1037 |
| %reg1081 = MOV32rm %reg1058, 1, %noreg, 0 |
| %reg1038 = LEA32r %reg1081, 1, %reg1080, -3 |
| %reg1036 = MOV32rm %reg1024, 1, %noreg, 32 |
| %reg1082 = SHL32ri %reg1038, 4 |
| %reg1039 = ADD32rr %reg1036, %reg1082 |
| %reg1083 = MOVAPSrm %reg1059, 1, %noreg, 0 |
| %reg1034 = SHUFPSrr %reg1083, %reg1083, 170 |
| %reg1032 = SHUFPSrr %reg1083, %reg1083, 0 |
| %reg1035 = SHUFPSrr %reg1083, %reg1083, 255 |
| %reg1033 = SHUFPSrr %reg1083, %reg1083, 85 |
| %reg1040 = MOV32rr %reg1039 |
| %reg1084 = AND32ri8 %reg1039, 15 |
| CMP32ri8 %reg1084, 0 |
| JE mbb<cond_next204,0xa914d30> |
| |
| Still ok. After register allocation: |
| |
| cond_next140 (0xa910740, LLVM BB @0xa90beb0): |
| %eax = MOV32ri -3 |
| %edx = MOV32rm %stack.3, 1, %noreg, 0 |
| ADD32rm %eax<def&use>, %edx, 1, %noreg, 0 |
| %edx = MOV32rm %stack.7, 1, %noreg, 0 |
| %edx = MOV32rm %edx, 1, %noreg, 40 |
| IMUL32rr %eax<def&use>, %edx |
| %esi = MOV32rm %stack.5, 1, %noreg, 0 |
| %esi = MOV32rm %esi, 1, %noreg, 0 |
| MOV32mr %stack.4, 1, %noreg, 0, %esi |
| %eax = LEA32r %esi, 1, %eax, -3 |
| %esi = MOV32rm %stack.7, 1, %noreg, 0 |
| %esi = MOV32rm %esi, 1, %noreg, 32 |
| %edi = MOV32rr %eax |
| SHL32ri %edi<def&use>, 4 |
| ADD32rr %edi<def&use>, %esi |
| %xmm0 = MOVAPSrm %ecx, 1, %noreg, 0 |
| %xmm1 = MOVAPSrr %xmm0 |
| SHUFPSrr %xmm1<def&use>, %xmm1, 170 |
| %xmm2 = MOVAPSrr %xmm0 |
| SHUFPSrr %xmm2<def&use>, %xmm2, 0 |
| %xmm3 = MOVAPSrr %xmm0 |
| SHUFPSrr %xmm3<def&use>, %xmm3, 255 |
| SHUFPSrr %xmm0<def&use>, %xmm0, 85 |
| %ebx = MOV32rr %edi |
| AND32ri8 %ebx<def&use>, 15 |
| CMP32ri8 %ebx, 0 |
| JE mbb<cond_next204,0xa914d30> |
| |
| This looks really bad. The problem is shufps is a destructive opcode. Since it |
| appears as operand two in more than one shufps ops. It resulted in a number of |
| copies. Note icc also suffers from the same problem. Either the instruction |
| selector should select pshufd or The register allocator can made the two-address |
| to three-address transformation. |
| |
| It also exposes some other problems. See MOV32ri -3 and the spills. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Consider: |
| |
| __m128 test(float a) { |
| return _mm_set_ps(0.0, 0.0, 0.0, a*a); |
| } |
| |
| This compiles into: |
| |
| movss 4(%esp), %xmm1 |
| mulss %xmm1, %xmm1 |
| xorps %xmm0, %xmm0 |
| movss %xmm1, %xmm0 |
| ret |
| |
| Because mulss doesn't modify the top 3 elements, the top elements of |
| xmm1 are already zero'd. We could compile this to: |
| |
| movss 4(%esp), %xmm0 |
| mulss %xmm0, %xmm0 |
| ret |
| |
| //===---------------------------------------------------------------------===// |
| |
| Here's a sick and twisted idea. Consider code like this: |
| |
| __m128 test(__m128 a) { |
| float b = *(float*)&A; |
| ... |
| return _mm_set_ps(0.0, 0.0, 0.0, b); |
| } |
| |
| This might compile to this code: |
| |
| movaps c(%esp), %xmm1 |
| xorps %xmm0, %xmm0 |
| movss %xmm1, %xmm0 |
| ret |
| |
| Now consider if the ... code caused xmm1 to get spilled. This might produce |
| this code: |
| |
| movaps c(%esp), %xmm1 |
| movaps %xmm1, c2(%esp) |
| ... |
| |
| xorps %xmm0, %xmm0 |
| movaps c2(%esp), %xmm1 |
| movss %xmm1, %xmm0 |
| ret |
| |
| However, since the reload is only used by these instructions, we could |
| "fold" it into the uses, producing something like this: |
| |
| movaps c(%esp), %xmm1 |
| movaps %xmm1, c2(%esp) |
| ... |
| |
| movss c2(%esp), %xmm0 |
| ret |
| |
| ... saving two instructions. |
| |
| The basic idea is that a reload from a spill slot, can, if only one 4-byte |
| chunk is used, bring in 3 zeros the one element instead of 4 elements. |
| This can be used to simplify a variety of shuffle operations, where the |
| elements are fixed zeros. |
| |
| //===---------------------------------------------------------------------===// |
| |
| This code generates ugly code, probably due to costs being off or something: |
| |
| define void @test(float* %P, <4 x float>* %P2 ) { |
| %xFloat0.688 = load float* %P |
| %tmp = load <4 x float>* %P2 |
| %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3 |
| store <4 x float> %inFloat3.713, <4 x float>* %P2 |
| ret void |
| } |
| |
| Generates: |
| |
| _test: |
| movl 8(%esp), %eax |
| movaps (%eax), %xmm0 |
| pxor %xmm1, %xmm1 |
| movaps %xmm0, %xmm2 |
| shufps $50, %xmm1, %xmm2 |
| shufps $132, %xmm2, %xmm0 |
| movaps %xmm0, (%eax) |
| ret |
| |
| Would it be better to generate: |
| |
| _test: |
| movl 8(%esp), %ecx |
| movaps (%ecx), %xmm0 |
| xor %eax, %eax |
| pinsrw $6, %eax, %xmm0 |
| pinsrw $7, %eax, %xmm0 |
| movaps %xmm0, (%ecx) |
| ret |
| |
| ? |
| |
| //===---------------------------------------------------------------------===// |
| |
| Some useful information in the Apple Altivec / SSE Migration Guide: |
| |
| http://developer.apple.com/documentation/Performance/Conceptual/ |
| Accelerate_sse_migration/index.html |
| |
| e.g. SSE select using and, andnot, or. Various SSE compare translations. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Add hooks to commute some CMPP operations. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Apply the same transformation that merged four float into a single 128-bit load |
| to loads from constant pool. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Floating point max / min are commutable when -enable-unsafe-fp-path is |
| specified. We should turn int_x86_sse_max_ss and X86ISD::FMIN etc. into other |
| nodes which are selected to max / min instructions that are marked commutable. |
| |
| //===---------------------------------------------------------------------===// |
| |
| We should materialize vector constants like "all ones" and "signbit" with |
| code like: |
| |
| cmpeqps xmm1, xmm1 ; xmm1 = all-ones |
| |
| and: |
| cmpeqps xmm1, xmm1 ; xmm1 = all-ones |
| psrlq xmm1, 31 ; xmm1 = all 100000000000... |
| |
| instead of using a load from the constant pool. The later is important for |
| ABS/NEG/copysign etc. |
| |
| //===---------------------------------------------------------------------===// |
| |
| These functions: |
| |
| #include <xmmintrin.h> |
| __m128i a; |
| void x(unsigned short n) { |
| a = _mm_slli_epi32 (a, n); |
| } |
| void y(unsigned n) { |
| a = _mm_slli_epi32 (a, n); |
| } |
| |
| compile to ( -O3 -static -fomit-frame-pointer): |
| _x: |
| movzwl 4(%esp), %eax |
| movd %eax, %xmm0 |
| movaps _a, %xmm1 |
| pslld %xmm0, %xmm1 |
| movaps %xmm1, _a |
| ret |
| _y: |
| movd 4(%esp), %xmm0 |
| movaps _a, %xmm1 |
| pslld %xmm0, %xmm1 |
| movaps %xmm1, _a |
| ret |
| |
| "y" looks good, but "x" does silly movzwl stuff around into a GPR. It seems |
| like movd would be sufficient in both cases as the value is already zero |
| extended in the 32-bit stack slot IIRC. For signed short, it should also be |
| save, as a really-signed value would be undefined for pslld. |
| |
| |
| //===---------------------------------------------------------------------===// |
| |
| #include <math.h> |
| int t1(double d) { return signbit(d); } |
| |
| This currently compiles to: |
| subl $12, %esp |
| movsd 16(%esp), %xmm0 |
| movsd %xmm0, (%esp) |
| movl 4(%esp), %eax |
| shrl $31, %eax |
| addl $12, %esp |
| ret |
| |
| We should use movmskp{s|d} instead. |
| |
| //===---------------------------------------------------------------------===// |
| |
| CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single |
| (aligned) vector load. This functionality has a couple of problems. |
| |
| 1. The code to infer alignment from loads of globals is in the X86 backend, |
| not the dag combiner. This is because dagcombine2 needs to be able to see |
| through the X86ISD::Wrapper node, which DAGCombine can't really do. |
| 2. The code for turning 4 x load into a single vector load is target |
| independent and should be moved to the dag combiner. |
| 3. The code for turning 4 x load into a vector load can only handle a direct |
| load from a global or a direct load from the stack. It should be generalized |
| to handle any load from P, P+4, P+8, P+12, where P can be anything. |
| 4. The alignment inference code cannot handle loads from globals in non-static |
| mode because it doesn't look through the extra dyld stub load. If you try |
| vec_align.ll without -relocation-model=static, you'll see what I mean. |
| |
| //===---------------------------------------------------------------------===// |
| |
| We should lower store(fneg(load p), q) into an integer load+xor+store, which |
| eliminates a constant pool load. For example, consider: |
| |
| define i64 @ccosf(float %z.0, float %z.1) nounwind readonly { |
| entry: |
| %tmp6 = fsub float -0.000000e+00, %z.1 ; <float> [#uses=1] |
| %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly |
| ret i64 %tmp20 |
| } |
| declare i64 @ccoshf(float %z.0, float %z.1) nounwind readonly |
| |
| This currently compiles to: |
| |
| LCPI1_0: # <4 x float> |
| .long 2147483648 # float -0 |
| .long 2147483648 # float -0 |
| .long 2147483648 # float -0 |
| .long 2147483648 # float -0 |
| _ccosf: |
| subl $12, %esp |
| movss 16(%esp), %xmm0 |
| movss %xmm0, 4(%esp) |
| movss 20(%esp), %xmm0 |
| xorps LCPI1_0, %xmm0 |
| movss %xmm0, (%esp) |
| call L_ccoshf$stub |
| addl $12, %esp |
| ret |
| |
| Note the load into xmm0, then xor (to negate), then store. In PIC mode, |
| this code computes the pic base and does two loads to do the constant pool |
| load, so the improvement is much bigger. |
| |
| The tricky part about this xform is that the argument load/store isn't exposed |
| until post-legalize, and at that point, the fneg has been custom expanded into |
| an X86 fxor. This means that we need to handle this case in the x86 backend |
| instead of in target independent code. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Non-SSE4 insert into 16 x i8 is atrociously bad. |
| |
| //===---------------------------------------------------------------------===// |
| |
| <2 x i64> extract is substantially worse than <2 x f64>, even if the destination |
| is memory. |
| |
| //===---------------------------------------------------------------------===// |
| |
| INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert |
| any number of 0.0 simultaneously. Currently we only use it for simple |
| insertions. |
| |
| See comments in LowerINSERT_VECTOR_ELT_SSE4. |
| |
| //===---------------------------------------------------------------------===// |
| |
| On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not |
| Custom. All combinations of insert/extract reg-reg, reg-mem, and mem-reg are |
| legal, it'll just take a few extra patterns written in the .td file. |
| |
| Note: this is not a code quality issue; the custom lowered code happens to be |
| right, but we shouldn't have to custom lower anything. This is probably related |
| to <2 x i64> ops being so bad. |
| |
| //===---------------------------------------------------------------------===// |
| |
| LLVM currently generates stack realignment code, when it is not necessary |
| needed. The problem is that we need to know about stack alignment too early, |
| before RA runs. |
| |
| At that point we don't know, whether there will be vector spill, or not. |
| Stack realignment logic is overly conservative here, but otherwise we can |
| produce unaligned loads/stores. |
| |
| Fixing this will require some huge RA changes. |
| |
| Testcase: |
| #include <emmintrin.h> |
| |
| typedef short vSInt16 __attribute__ ((__vector_size__ (16))); |
| |
| static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873, |
| - 22725, - 12873};; |
| |
| vSInt16 madd(vSInt16 b) |
| { |
| return _mm_madd_epi16(a, b); |
| } |
| |
| Generated code (x86-32, linux): |
| madd: |
| pushl %ebp |
| movl %esp, %ebp |
| andl $-16, %esp |
| movaps .LCPI1_0, %xmm1 |
| pmaddwd %xmm1, %xmm0 |
| movl %ebp, %esp |
| popl %ebp |
| ret |
| |
| //===---------------------------------------------------------------------===// |
| |
| Consider: |
| #include <emmintrin.h> |
| __m128 foo2 (float x) { |
| return _mm_set_ps (0, 0, x, 0); |
| } |
| |
| In x86-32 mode, we generate this spiffy code: |
| |
| _foo2: |
| movss 4(%esp), %xmm0 |
| pshufd $81, %xmm0, %xmm0 |
| ret |
| |
| in x86-64 mode, we generate this code, which could be better: |
| |
| _foo2: |
| xorps %xmm1, %xmm1 |
| movss %xmm0, %xmm1 |
| pshufd $81, %xmm1, %xmm0 |
| ret |
| |
| In sse4 mode, we could use insertps to make both better. |
| |
| Here's another testcase that could use insertps [mem]: |
| |
| #include <xmmintrin.h> |
| extern float x2, x3; |
| __m128 foo1 (float x1, float x4) { |
| return _mm_set_ps (x2, x1, x3, x4); |
| } |
| |
| gcc mainline compiles it to: |
| |
| foo1: |
| insertps $0x10, x2(%rip), %xmm0 |
| insertps $0x10, x3(%rip), %xmm1 |
| movaps %xmm1, %xmm2 |
| movlhps %xmm0, %xmm2 |
| movaps %xmm2, %xmm0 |
| ret |
| |
| //===---------------------------------------------------------------------===// |
| |
| We compile vector multiply-by-constant into poor code: |
| |
| define <4 x i32> @f(<4 x i32> %i) nounwind { |
| %A = mul <4 x i32> %i, < i32 10, i32 10, i32 10, i32 10 > |
| ret <4 x i32> %A |
| } |
| |
| On targets without SSE4.1, this compiles into: |
| |
| LCPI1_0: ## <4 x i32> |
| .long 10 |
| .long 10 |
| .long 10 |
| .long 10 |
| .text |
| .align 4,0x90 |
| .globl _f |
| _f: |
| pshufd $3, %xmm0, %xmm1 |
| movd %xmm1, %eax |
| imull LCPI1_0+12, %eax |
| movd %eax, %xmm1 |
| pshufd $1, %xmm0, %xmm2 |
| movd %xmm2, %eax |
| imull LCPI1_0+4, %eax |
| movd %eax, %xmm2 |
| punpckldq %xmm1, %xmm2 |
| movd %xmm0, %eax |
| imull LCPI1_0, %eax |
| movd %eax, %xmm1 |
| movhlps %xmm0, %xmm0 |
| movd %xmm0, %eax |
| imull LCPI1_0+8, %eax |
| movd %eax, %xmm0 |
| punpckldq %xmm0, %xmm1 |
| movaps %xmm1, %xmm0 |
| punpckldq %xmm2, %xmm0 |
| ret |
| |
| It would be better to synthesize integer vector multiplication by constants |
| using shifts and adds, pslld and paddd here. And even on targets with SSE4.1, |
| simple cases such as multiplication by powers of two would be better as |
| vector shifts than as multiplications. |
| |
| //===---------------------------------------------------------------------===// |
| |
| We compile this: |
| |
| __m128i |
| foo2 (char x) |
| { |
| return _mm_set_epi8 (1, 0, 0, 0, 0, 0, 0, 0, 0, x, 0, 1, 0, 0, 0, 0); |
| } |
| |
| into: |
| movl $1, %eax |
| xorps %xmm0, %xmm0 |
| pinsrw $2, %eax, %xmm0 |
| movzbl 4(%esp), %eax |
| pinsrw $3, %eax, %xmm0 |
| movl $256, %eax |
| pinsrw $7, %eax, %xmm0 |
| ret |
| |
| |
| gcc-4.2: |
| subl $12, %esp |
| movzbl 16(%esp), %eax |
| movdqa LC0, %xmm0 |
| pinsrw $3, %eax, %xmm0 |
| addl $12, %esp |
| ret |
| .const |
| .align 4 |
| LC0: |
| .word 0 |
| .word 0 |
| .word 1 |
| .word 0 |
| .word 0 |
| .word 0 |
| .word 0 |
| .word 256 |
| |
| With SSE4, it should be |
| movdqa .LC0(%rip), %xmm0 |
| pinsrb $6, %edi, %xmm0 |
| |
| //===---------------------------------------------------------------------===// |
| |
| We should transform a shuffle of two vectors of constants into a single vector |
| of constants. Also, insertelement of a constant into a vector of constants |
| should also result in a vector of constants. e.g. 2008-06-25-VecISelBug.ll. |
| |
| We compiled it to something horrible: |
| |
| .align 4 |
| LCPI1_1: ## float |
| .long 1065353216 ## float 1 |
| .const |
| |
| .align 4 |
| LCPI1_0: ## <4 x float> |
| .space 4 |
| .long 1065353216 ## float 1 |
| .space 4 |
| .long 1065353216 ## float 1 |
| .text |
| .align 4,0x90 |
| .globl _t |
| _t: |
| xorps %xmm0, %xmm0 |
| movhps LCPI1_0, %xmm0 |
| movss LCPI1_1, %xmm1 |
| movaps %xmm0, %xmm2 |
| shufps $2, %xmm1, %xmm2 |
| shufps $132, %xmm2, %xmm0 |
| movaps %xmm0, 0 |
| |
| //===---------------------------------------------------------------------===// |
| rdar://5907648 |
| |
| This function: |
| |
| float foo(unsigned char x) { |
| return x; |
| } |
| |
| compiles to (x86-32): |
| |
| define float @foo(i8 zeroext %x) nounwind { |
| %tmp12 = uitofp i8 %x to float ; <float> [#uses=1] |
| ret float %tmp12 |
| } |
| |
| compiles to: |
| |
| _foo: |
| subl $4, %esp |
| movzbl 8(%esp), %eax |
| cvtsi2ss %eax, %xmm0 |
| movss %xmm0, (%esp) |
| flds (%esp) |
| addl $4, %esp |
| ret |
| |
| We should be able to use: |
| cvtsi2ss 8($esp), %xmm0 |
| since we know the stack slot is already zext'd. |
| |
| //===---------------------------------------------------------------------===// |
| |
| Consider using movlps instead of movsd to implement (scalar_to_vector (loadf64)) |
| when code size is critical. movlps is slower than movsd on core2 but it's one |
| byte shorter. |
| |
| //===---------------------------------------------------------------------===// |
| |
| We should use a dynamic programming based approach to tell when using FPStack |
| operations is cheaper than SSE. SciMark montecarlo contains code like this |
| for example: |
| |
| double MonteCarlo_num_flops(int Num_samples) { |
| return ((double) Num_samples)* 4.0; |
| } |
| |
| In fpstack mode, this compiles into: |
| |
| LCPI1_0: |
| .long 1082130432 ## float 4.000000e+00 |
| _MonteCarlo_num_flops: |
| subl $4, %esp |
| movl 8(%esp), %eax |
| movl %eax, (%esp) |
| fildl (%esp) |
| fmuls LCPI1_0 |
| addl $4, %esp |
| ret |
| |
| in SSE mode, it compiles into significantly slower code: |
| |
| _MonteCarlo_num_flops: |
| subl $12, %esp |
| cvtsi2sd 16(%esp), %xmm0 |
| mulsd LCPI1_0, %xmm0 |
| movsd %xmm0, (%esp) |
| fldl (%esp) |
| addl $12, %esp |
| ret |
| |
| There are also other cases in scimark where using fpstack is better, it is |
| cheaper to do fld1 than load from a constant pool for example, so |
| "load, add 1.0, store" is better done in the fp stack, etc. |
| |
| //===---------------------------------------------------------------------===// |
| |
| These should compile into the same code (PR6214): Perhaps instcombine should |
| canonicalize the former into the later? |
| |
| define float @foo(float %x) nounwind { |
| %t = bitcast float %x to i32 |
| %s = and i32 %t, 2147483647 |
| %d = bitcast i32 %s to float |
| ret float %d |
| } |
| |
| declare float @fabsf(float %n) |
| define float @bar(float %x) nounwind { |
| %d = call float @fabsf(float %x) |
| ret float %d |
| } |
| |
| //===---------------------------------------------------------------------===// |
| |
| This IR (from PR6194): |
| |
| 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-S128" |
| target triple = "x86_64-apple-darwin10.0.0" |
| |
| %0 = type { double, double } |
| %struct.float3 = type { float, float, float } |
| |
| define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp { |
| entry: |
| %tmp18 = extractvalue %0 %0, 0 ; <double> [#uses=1] |
| %tmp19 = bitcast double %tmp18 to i64 ; <i64> [#uses=1] |
| %tmp20 = zext i64 %tmp19 to i128 ; <i128> [#uses=1] |
| %tmp10 = lshr i128 %tmp20, 32 ; <i128> [#uses=1] |
| %tmp11 = trunc i128 %tmp10 to i32 ; <i32> [#uses=1] |
| %tmp12 = bitcast i32 %tmp11 to float ; <float> [#uses=1] |
| %tmp5 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ; <float*> [#uses=1] |
| store float %tmp12, float* %tmp5 |
| ret void |
| } |
| |
| Compiles to: |
| |
| _test: ## @test |
| movd %xmm0, %rax |
| shrq $32, %rax |
| movl %eax, 4(%rdi) |
| ret |
| |
| This would be better kept in the SSE unit by treating XMM0 as a 4xfloat and |
| doing a shuffle from v[1] to v[0] then a float store. |
| |
| //===---------------------------------------------------------------------===// |
| |
| [UNSAFE FP] |
| |
| void foo(double, double, double); |
| void norm(double x, double y, double z) { |
| double scale = __builtin_sqrt(x*x + y*y + z*z); |
| foo(x/scale, y/scale, z/scale); |
| } |
| |
| We currently generate an sqrtsd and 3 divsd instructions. This is bad, fp div is |
| slow and not pipelined. In -ffast-math mode we could compute "1.0/scale" first |
| and emit 3 mulsd in place of the divs. This can be done as a target-independent |
| transform. |
| |
| If we're dealing with floats instead of doubles we could even replace the sqrtss |
| and inversion with an rsqrtss instruction, which computes 1/sqrt faster at the |
| cost of reduced accuracy. |
| |
| //===---------------------------------------------------------------------===// |
| |
| This function should be matched to haddpd when the appropriate CPU is enabled: |
| |
| #include <x86intrin.h> |
| double f (__m128d p) { |
| return p[0] + p[1]; |
| } |
| |
| similarly, v[0]-v[1] should match to hsubpd, and {v[0]-v[1], w[0]-w[1]} should |
| turn into hsubpd also. |
| |
| //===---------------------------------------------------------------------===// |
