lib/Target/X86/README-SSE.txt

   1 //===---------------------------------------------------------------------===//
   2 // Random ideas for the X86 backend: SSE-specific stuff.
   3 //===---------------------------------------------------------------------===//
   4
   5 //===---------------------------------------------------------------------===//
   6
   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.
   9
  10 __m128i_shift_right:
  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
  13
  14 ...
  15 __m128i shift_right(__m128i value, unsigned long offset) {
  16   return _mm_shuffle_epi8(value,
  17                _mm_loadu_si128((__m128 *) (___m128i_shift_right + offset)));
  18 }
  19
  20 //===---------------------------------------------------------------------===//
  21
  22 SSE has instructions for doing operations on complex numbers, we should pattern
  23 match them.   For example, this should turn into a horizontal add:
  24
  25 typedef float __attribute__((vector_size(16))) v4f32;
  26 float f32(v4f32 A) {
  27   return A[0]+A[1]+A[2]+A[3];
  28 }
  29
  30 Instead we get this:
  31
  32 _f32:                                   ## @f32
  33         pshufd  $1, %xmm0, %xmm1        ## xmm1 = xmm0[1,0,0,0]
  34         addss   %xmm0, %xmm1
  35         pshufd  $3, %xmm0, %xmm2        ## xmm2 = xmm0[3,0,0,0]
  36         movhlps %xmm0, %xmm0            ## xmm0 = xmm0[1,1]
  37         movaps  %xmm0, %xmm3
  38         addss   %xmm1, %xmm3
  39         movdqa  %xmm2, %xmm0
  40         addss   %xmm3, %xmm0
  41         ret
  42
  43 Also, there are cases where some simple local SLP would improve codegen a bit.
  44 compiling this:
  45
  46 _Complex float f32(_Complex float A, _Complex float B) {
  47   return A+B;
  48 }
  49
  50 into:
  51
  52 _f32:                                   ## @f32
  53         movdqa  %xmm0, %xmm2
  54         addss   %xmm1, %xmm2
  55         pshufd  $1, %xmm1, %xmm1        ## xmm1 = xmm1[1,0,0,0]
  56         pshufd  $1, %xmm0, %xmm3        ## xmm3 = xmm0[1,0,0,0]
  57         addss   %xmm1, %xmm3
  58         movaps  %xmm2, %xmm0
  59         unpcklps        %xmm3, %xmm0    ## xmm0 = xmm0[0],xmm3[0],xmm0[1],xmm3[1]
  60         ret
  61
  62 seems silly when it could just be one addps.
  63
  64
  65 //===---------------------------------------------------------------------===//
  66
  67 Expand libm rounding functions inline:  Significant speedups possible.
  68 http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00909.html
  69
  70 //===---------------------------------------------------------------------===//
  71
  72 When compiled with unsafemath enabled, "main" should enable SSE DAZ mode and
  73 other fast SSE modes.
  74
  75 //===---------------------------------------------------------------------===//
  76
  77 Think about doing i64 math in SSE regs on x86-32.
  78
  79 //===---------------------------------------------------------------------===//
  80
  81 This testcase should have no SSE instructions in it, and only one load from
  82 a constant pool:
  83
  84 double %test3(bool %B) {
  85         %C = select bool %B, double 123.412, double 523.01123123
  86         ret double %C
  87 }
  88
  89 Currently, the select is being lowered, which prevents the dag combiner from
  90 turning 'select (load CPI1), (load CPI2)' -> 'load (select CPI1, CPI2)'
  91
  92 The pattern isel got this one right.
  93
  94 //===---------------------------------------------------------------------===//
  95
  96 SSE should implement 'select_cc' using 'emulated conditional moves' that use
  97 pcmp/pand/pandn/por to do a selection instead of a conditional branch:
  98
  99 double %X(double %Y, double %Z, double %A, double %B) {
 100         %C = setlt double %A, %B
 101         %z = fadd double %Z, 0.0    ;; select operand is not a load
 102         %D = select bool %C, double %Y, double %z
 103         ret double %D
 104 }
 105
 106 We currently emit:
 107
 108 _X:
 109         subl $12, %esp
 110         xorpd %xmm0, %xmm0
 111         addsd 24(%esp), %xmm0
 112         movsd 32(%esp), %xmm1
 113         movsd 16(%esp), %xmm2
 114         ucomisd 40(%esp), %xmm1
 115         jb LBB_X_2
 116 LBB_X_1:
 117         movsd %xmm0, %xmm2
 118 LBB_X_2:
 119         movsd %xmm2, (%esp)
 120         fldl (%esp)
 121         addl $12, %esp
 122         ret
 123
 124 //===---------------------------------------------------------------------===//
 125
 126 Lower memcpy / memset to a series of SSE 128 bit move instructions when it's
 127 feasible.
 128
 129 //===---------------------------------------------------------------------===//
 130
 131 Codegen:
 132   if (copysign(1.0, x) == copysign(1.0, y))
 133 into:
 134   if (x^y & mask)
 135 when using SSE.
 136
 137 //===---------------------------------------------------------------------===//
 138
 139 Use movhps to update upper 64-bits of a v4sf value. Also movlps on lower half
 140 of a v4sf value.
 141
 142 //===---------------------------------------------------------------------===//
 143
 144 Better codegen for vector_shuffles like this { x, 0, 0, 0 } or { x, 0, x, 0}.
 145 Perhaps use pxor / xorp* to clear a XMM register first?
 146
 147 //===---------------------------------------------------------------------===//
 148
 149 External test Nurbs exposed some problems. Look for
 150 __ZN15Nurbs_SSE_Cubic17TessellateSurfaceE, bb cond_next140. This is what icc
 151 emits:
 152
 153         movaps    (%edx), %xmm2                                 #59.21
 154         movaps    (%edx), %xmm5                                 #60.21
 155         movaps    (%edx), %xmm4                                 #61.21
 156         movaps    (%edx), %xmm3                                 #62.21
 157         movl      40(%ecx), %ebp                                #69.49
 158         shufps    $0, %xmm2, %xmm5                              #60.21
 159         movl      100(%esp), %ebx                               #69.20
 160         movl      (%ebx), %edi                                  #69.20
 161         imull     %ebp, %edi                                    #69.49
 162         addl      (%eax), %edi                                  #70.33
 163         shufps    $85, %xmm2, %xmm4                             #61.21
 164         shufps    $170, %xmm2, %xmm3                            #62.21
 165         shufps    $255, %xmm2, %xmm2                            #63.21
 166         lea       (%ebp,%ebp,2), %ebx                           #69.49
 167         negl      %ebx                                          #69.49
 168         lea       -3(%edi,%ebx), %ebx                           #70.33
 169         shll      $4, %ebx                                      #68.37
 170         addl      32(%ecx), %ebx                                #68.37
 171         testb     $15, %bl                                      #91.13
 172         jne       L_B1.24       # Prob 5%                       #91.13
 173
 174 This is the llvm code after instruction scheduling:
 175
 176 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
 177         %reg1078 = MOV32ri -3
 178         %reg1079 = ADD32rm %reg1078, %reg1068, 1, %NOREG, 0
 179         %reg1037 = MOV32rm %reg1024, 1, %NOREG, 40
 180         %reg1080 = IMUL32rr %reg1079, %reg1037
 181         %reg1081 = MOV32rm %reg1058, 1, %NOREG, 0
 182         %reg1038 = LEA32r %reg1081, 1, %reg1080, -3
 183         %reg1036 = MOV32rm %reg1024, 1, %NOREG, 32
 184         %reg1082 = SHL32ri %reg1038, 4
 185         %reg1039 = ADD32rr %reg1036, %reg1082
 186         %reg1083 = MOVAPSrm %reg1059, 1, %NOREG, 0
 187         %reg1034 = SHUFPSrr %reg1083, %reg1083, 170
 188         %reg1032 = SHUFPSrr %reg1083, %reg1083, 0
 189         %reg1035 = SHUFPSrr %reg1083, %reg1083, 255
 190         %reg1033 = SHUFPSrr %reg1083, %reg1083, 85
 191         %reg1040 = MOV32rr %reg1039
 192         %reg1084 = AND32ri8 %reg1039, 15
 193         CMP32ri8 %reg1084, 0
 194         JE mbb<cond_next204,0xa914d30>
 195
 196 Still ok. After register allocation:
 197
 198 cond_next140 (0xa910740, LLVM BB @0xa90beb0):
 199         %EAX = MOV32ri -3
 200         %EDX = MOV32rm <fi#3>, 1, %NOREG, 0
 201         ADD32rm %EAX<def&use>, %EDX, 1, %NOREG, 0
 202         %EDX = MOV32rm <fi#7>, 1, %NOREG, 0
 203         %EDX = MOV32rm %EDX, 1, %NOREG, 40
 204         IMUL32rr %EAX<def&use>, %EDX
 205         %ESI = MOV32rm <fi#5>, 1, %NOREG, 0
 206         %ESI = MOV32rm %ESI, 1, %NOREG, 0
 207         MOV32mr <fi#4>, 1, %NOREG, 0, %ESI
 208         %EAX = LEA32r %ESI, 1, %EAX, -3
 209         %ESI = MOV32rm <fi#7>, 1, %NOREG, 0
 210         %ESI = MOV32rm %ESI, 1, %NOREG, 32
 211         %EDI = MOV32rr %EAX
 212         SHL32ri %EDI<def&use>, 4
 213         ADD32rr %EDI<def&use>, %ESI
 214         %XMM0 = MOVAPSrm %ECX, 1, %NOREG, 0
 215         %XMM1 = MOVAPSrr %XMM0
 216         SHUFPSrr %XMM1<def&use>, %XMM1, 170
 217         %XMM2 = MOVAPSrr %XMM0
 218         SHUFPSrr %XMM2<def&use>, %XMM2, 0
 219         %XMM3 = MOVAPSrr %XMM0
 220         SHUFPSrr %XMM3<def&use>, %XMM3, 255
 221         SHUFPSrr %XMM0<def&use>, %XMM0, 85
 222         %EBX = MOV32rr %EDI
 223         AND32ri8 %EBX<def&use>, 15
 224         CMP32ri8 %EBX, 0
 225         JE mbb<cond_next204,0xa914d30>
 226
 227 This looks really bad. The problem is shufps is a destructive opcode. Since it
 228 appears as operand two in more than one shufps ops. It resulted in a number of
 229 copies. Note icc also suffers from the same problem. Either the instruction
 230 selector should select pshufd or The register allocator can made the two-address
 231 to three-address transformation.
 232
 233 It also exposes some other problems. See MOV32ri -3 and the spills.
 234
 235 //===---------------------------------------------------------------------===//
 236
 237 Consider:
 238
 239 __m128 test(float a) {
 240   return _mm_set_ps(0.0, 0.0, 0.0, a*a);
 241 }
 242
 243 This compiles into:
 244
 245 movss 4(%esp), %xmm1
 246 mulss %xmm1, %xmm1
 247 xorps %xmm0, %xmm0
 248 movss %xmm1, %xmm0
 249 ret
 250
 251 Because mulss doesn't modify the top 3 elements, the top elements of
 252 xmm1 are already zero'd.  We could compile this to:
 253
 254 movss 4(%esp), %xmm0
 255 mulss %xmm0, %xmm0
 256 ret
 257
 258 //===---------------------------------------------------------------------===//
 259
 260 Here's a sick and twisted idea.  Consider code like this:
 261
 262 __m128 test(__m128 a) {
 263   float b = *(float*)&A;
 264   ...
 265   return _mm_set_ps(0.0, 0.0, 0.0, b);
 266 }
 267
 268 This might compile to this code:
 269
 270 movaps c(%esp), %xmm1
 271 xorps %xmm0, %xmm0
 272 movss %xmm1, %xmm0
 273 ret
 274
 275 Now consider if the ... code caused xmm1 to get spilled.  This might produce
 276 this code:
 277
 278 movaps c(%esp), %xmm1
 279 movaps %xmm1, c2(%esp)
 280 ...
 281
 282 xorps %xmm0, %xmm0
 283 movaps c2(%esp), %xmm1
 284 movss %xmm1, %xmm0
 285 ret
 286
 287 However, since the reload is only used by these instructions, we could
 288 "fold" it into the uses, producing something like this:
 289
 290 movaps c(%esp), %xmm1
 291 movaps %xmm1, c2(%esp)
 292 ...
 293
 294 movss c2(%esp), %xmm0
 295 ret
 296
 297 ... saving two instructions.
 298
 299 The basic idea is that a reload from a spill slot, can, if only one 4-byte
 300 chunk is used, bring in 3 zeros the one element instead of 4 elements.
 301 This can be used to simplify a variety of shuffle operations, where the
 302 elements are fixed zeros.
 303
 304 //===---------------------------------------------------------------------===//
 305
 306 This code generates ugly code, probably due to costs being off or something:
 307
 308 define void @test(float* %P, <4 x float>* %P2 ) {
 309         %xFloat0.688 = load float* %P
 310         %tmp = load <4 x float>* %P2
 311         %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3
 312         store <4 x float> %inFloat3.713, <4 x float>* %P2
 313         ret void
 314 }
 315
 316 Generates:
 317
 318 _test:
 319         movl    8(%esp), %eax
 320         movaps  (%eax), %xmm0
 321         pxor    %xmm1, %xmm1
 322         movaps  %xmm0, %xmm2
 323         shufps  $50, %xmm1, %xmm2
 324         shufps  $132, %xmm2, %xmm0
 325         movaps  %xmm0, (%eax)
 326         ret
 327
 328 Would it be better to generate:
 329
 330 _test:
 331         movl 8(%esp), %ecx
 332         movaps (%ecx), %xmm0
 333         xor %eax, %eax
 334         pinsrw $6, %eax, %xmm0
 335         pinsrw $7, %eax, %xmm0
 336         movaps %xmm0, (%ecx)
 337         ret
 338
 339 ?
 340
 341 //===---------------------------------------------------------------------===//
 342
 343 Some useful information in the Apple Altivec / SSE Migration Guide:
 344
 345 http://developer.apple.com/documentation/Performance/Conceptual/
 346 Accelerate_sse_migration/index.html
 347
 348 e.g. SSE select using and, andnot, or. Various SSE compare translations.
 349
 350 //===---------------------------------------------------------------------===//
 351
 352 Add hooks to commute some CMPP operations.
 353
 354 //===---------------------------------------------------------------------===//
 355
 356 Apply the same transformation that merged four float into a single 128-bit load
 357 to loads from constant pool.
 358
 359 //===---------------------------------------------------------------------===//
 360
 361 Floating point max / min are commutable when -enable-unsafe-fp-path is
 362 specified. We should turn int_x86_sse_max_ss and X86ISD::FMIN etc. into other
 363 nodes which are selected to max / min instructions that are marked commutable.
 364
 365 //===---------------------------------------------------------------------===//
 366
 367 We should materialize vector constants like "all ones" and "signbit" with
 368 code like:
 369
 370      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
 371
 372 and:
 373      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
 374      psrlq   xmm1, 31     ; xmm1 = all 100000000000...
 375
 376 instead of using a load from the constant pool.  The later is important for
 377 ABS/NEG/copysign etc.
 378
 379 //===---------------------------------------------------------------------===//
 380
 381 These functions:
 382
 383 #include <xmmintrin.h>
 384 __m128i a;
 385 void x(unsigned short n) {
 386   a = _mm_slli_epi32 (a, n);
 387 }
 388 void y(unsigned n) {
 389   a = _mm_slli_epi32 (a, n);
 390 }
 391
 392 compile to ( -O3 -static -fomit-frame-pointer):
 393 _x:
 394         movzwl  4(%esp), %eax
 395         movd    %eax, %xmm0
 396         movaps  _a, %xmm1
 397         pslld   %xmm0, %xmm1
 398         movaps  %xmm1, _a
 399         ret
 400 _y:
 401         movd    4(%esp), %xmm0
 402         movaps  _a, %xmm1
 403         pslld   %xmm0, %xmm1
 404         movaps  %xmm1, _a
 405         ret
 406
 407 "y" looks good, but "x" does silly movzwl stuff around into a GPR.  It seems
 408 like movd would be sufficient in both cases as the value is already zero
 409 extended in the 32-bit stack slot IIRC.  For signed short, it should also be
 410 save, as a really-signed value would be undefined for pslld.
 411
 412
 413 //===---------------------------------------------------------------------===//
 414
 415 #include <math.h>
 416 int t1(double d) { return signbit(d); }
 417
 418 This currently compiles to:
 419         subl    $12, %esp
 420         movsd   16(%esp), %xmm0
 421         movsd   %xmm0, (%esp)
 422         movl    4(%esp), %eax
 423         shrl    $31, %eax
 424         addl    $12, %esp
 425         ret
 426
 427 We should use movmskp{s|d} instead.
 428
 429 //===---------------------------------------------------------------------===//
 430
 431 CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
 432 (aligned) vector load.  This functionality has a couple of problems.
 433
 434 1. The code to infer alignment from loads of globals is in the X86 backend,
 435    not the dag combiner.  This is because dagcombine2 needs to be able to see
 436    through the X86ISD::Wrapper node, which DAGCombine can't really do.
 437 2. The code for turning 4 x load into a single vector load is target
 438    independent and should be moved to the dag combiner.
 439 3. The code for turning 4 x load into a vector load can only handle a direct
 440    load from a global or a direct load from the stack.  It should be generalized
 441    to handle any load from P, P+4, P+8, P+12, where P can be anything.
 442 4. The alignment inference code cannot handle loads from globals in non-static
 443    mode because it doesn't look through the extra dyld stub load.  If you try
 444    vec_align.ll without -relocation-model=static, you'll see what I mean.
 445
 446 //===---------------------------------------------------------------------===//
 447
 448 We should lower store(fneg(load p), q) into an integer load+xor+store, which
 449 eliminates a constant pool load.  For example, consider:
 450
 451 define i64 @ccosf(float %z.0, float %z.1) nounwind readonly  {
 452 entry:
 453  %tmp6 = fsub float -0.000000e+00, %z.1         ; <float> [#uses=1]
 454  %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly
 455  ret i64 %tmp20
 456 }
 457 declare i64 @ccoshf(float %z.0, float %z.1) nounwind readonly
 458
 459 This currently compiles to:
 460
 461 LCPI1_0:                                        #  <4 x float>
 462         .long   2147483648      # float -0
 463         .long   2147483648      # float -0
 464         .long   2147483648      # float -0
 465         .long   2147483648      # float -0
 466 _ccosf:
 467         subl    $12, %esp
 468         movss   16(%esp), %xmm0
 469         movss   %xmm0, 4(%esp)
 470         movss   20(%esp), %xmm0
 471         xorps   LCPI1_0, %xmm0
 472         movss   %xmm0, (%esp)
 473         call    L_ccoshf$stub
 474         addl    $12, %esp
 475         ret
 476
 477 Note the load into xmm0, then xor (to negate), then store.  In PIC mode,
 478 this code computes the pic base and does two loads to do the constant pool
 479 load, so the improvement is much bigger.
 480
 481 The tricky part about this xform is that the argument load/store isn't exposed
 482 until post-legalize, and at that point, the fneg has been custom expanded into
 483 an X86 fxor.  This means that we need to handle this case in the x86 backend
 484 instead of in target independent code.
 485
 486 //===---------------------------------------------------------------------===//
 487
 488 Non-SSE4 insert into 16 x i8 is atrociously bad.
 489
 490 //===---------------------------------------------------------------------===//
 491
 492 <2 x i64> extract is substantially worse than <2 x f64>, even if the destination
 493 is memory.
 494
 495 //===---------------------------------------------------------------------===//
 496
 497 SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
 498 sitting between the truncate and the extract.
 499
 500 //===---------------------------------------------------------------------===//
 501
 502 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
 503 any number of 0.0 simultaneously.  Currently we only use it for simple
 504 insertions.
 505
 506 See comments in LowerINSERT_VECTOR_ELT_SSE4.
 507
 508 //===---------------------------------------------------------------------===//
 509
 510 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
 511 Custom.  All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
 512 legal, it'll just take a few extra patterns written in the .td file.
 513
 514 Note: this is not a code quality issue; the custom lowered code happens to be
 515 right, but we shouldn't have to custom lower anything.  This is probably related
 516 to <2 x i64> ops being so bad.
 517
 518 //===---------------------------------------------------------------------===//
 519
 520 'select' on vectors and scalars could be a whole lot better.  We currently
 521 lower them to conditional branches.  On x86-64 for example, we compile this:
 522
 523 double test(double a, double b, double c, double d) { return a<b ? c : d; }
 524
 525 to:
 526
 527 _test:
 528         ucomisd %xmm0, %xmm1
 529         ja      LBB1_2  # entry
 530 LBB1_1: # entry
 531         movapd  %xmm3, %xmm2
 532 LBB1_2: # entry
 533         movapd  %xmm2, %xmm0
 534         ret
 535
 536 instead of:
 537
 538 _test:
 539         cmpltsd %xmm1, %xmm0
 540         andpd   %xmm0, %xmm2
 541         andnpd  %xmm3, %xmm0
 542         orpd    %xmm2, %xmm0
 543         ret
 544
 545 For unpredictable branches, the later is much more efficient.  This should
 546 just be a matter of having scalar sse map to SELECT_CC and custom expanding
 547 or iseling it.
 548
 549 //===---------------------------------------------------------------------===//
 550
 551 LLVM currently generates stack realignment code, when it is not necessary
 552 needed. The problem is that we need to know about stack alignment too early,
 553 before RA runs.
 554
 555 At that point we don't know, whether there will be vector spill, or not.
 556 Stack realignment logic is overly conservative here, but otherwise we can
 557 produce unaligned loads/stores.
 558
 559 Fixing this will require some huge RA changes.
 560
 561 Testcase:
 562 #include <emmintrin.h>
 563
 564 typedef short vSInt16 __attribute__ ((__vector_size__ (16)));
 565
 566 static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,
 567 - 22725, - 12873};;
 568
 569 vSInt16 madd(vSInt16 b)
 570 {
 571     return _mm_madd_epi16(a, b);
 572 }
 573
 574 Generated code (x86-32, linux):
 575 madd:
 576         pushl   %ebp
 577         movl    %esp, %ebp
 578         andl    $-16, %esp
 579         movaps  .LCPI1_0, %xmm1
 580         pmaddwd %xmm1, %xmm0
 581         movl    %ebp, %esp
 582         popl    %ebp
 583         ret
 584
 585 //===---------------------------------------------------------------------===//
 586
 587 Consider:
 588 #include <emmintrin.h>
 589 __m128 foo2 (float x) {
 590  return _mm_set_ps (0, 0, x, 0);
 591 }
 592
 593 In x86-32 mode, we generate this spiffy code:
 594
 595 _foo2:
 596         movss   4(%esp), %xmm0
 597         pshufd  $81, %xmm0, %xmm0
 598         ret
 599
 600 in x86-64 mode, we generate this code, which could be better:
 601
 602 _foo2:
 603         xorps   %xmm1, %xmm1
 604         movss   %xmm0, %xmm1
 605         pshufd  $81, %xmm1, %xmm0
 606         ret
 607
 608 In sse4 mode, we could use insertps to make both better.
 609
 610 Here's another testcase that could use insertps [mem]:
 611
 612 #include <xmmintrin.h>
 613 extern float x2, x3;
 614 __m128 foo1 (float x1, float x4) {
 615  return _mm_set_ps (x2, x1, x3, x4);
 616 }
 617
 618 gcc mainline compiles it to:
 619
 620 foo1:
 621        insertps        $0x10, x2(%rip), %xmm0
 622        insertps        $0x10, x3(%rip), %xmm1
 623        movaps  %xmm1, %xmm2
 624        movlhps %xmm0, %xmm2
 625        movaps  %xmm2, %xmm0
 626        ret
 627
 628 //===---------------------------------------------------------------------===//
 629
 630 We compile vector multiply-by-constant into poor code:
 631
 632 define <4 x i32> @f(<4 x i32> %i) nounwind  {
 633         %A = mul <4 x i32> %i, < i32 10, i32 10, i32 10, i32 10 >
 634         ret <4 x i32> %A
 635 }
 636
 637 On targets without SSE4.1, this compiles into:
 638
 639 LCPI1_0:                                        ##  <4 x i32>
 640         .long   10
 641         .long   10
 642         .long   10
 643         .long   10
 644         .text
 645         .align  4,0x90
 646         .globl  _f
 647 _f:
 648         pshufd  $3, %xmm0, %xmm1
 649         movd    %xmm1, %eax
 650         imull   LCPI1_0+12, %eax
 651         movd    %eax, %xmm1
 652         pshufd  $1, %xmm0, %xmm2
 653         movd    %xmm2, %eax
 654         imull   LCPI1_0+4, %eax
 655         movd    %eax, %xmm2
 656         punpckldq       %xmm1, %xmm2
 657         movd    %xmm0, %eax
 658         imull   LCPI1_0, %eax
 659         movd    %eax, %xmm1
 660         movhlps %xmm0, %xmm0
 661         movd    %xmm0, %eax
 662         imull   LCPI1_0+8, %eax
 663         movd    %eax, %xmm0
 664         punpckldq       %xmm0, %xmm1
 665         movaps  %xmm1, %xmm0
 666         punpckldq       %xmm2, %xmm0
 667         ret
 668
 669 It would be better to synthesize integer vector multiplication by constants
 670 using shifts and adds, pslld and paddd here. And even on targets with SSE4.1,
 671 simple cases such as multiplication by powers of two would be better as
 672 vector shifts than as multiplications.
 673
 674 //===---------------------------------------------------------------------===//
 675
 676 We compile this:
 677
 678 __m128i
 679 foo2 (char x)
 680 {
 681   return _mm_set_epi8 (1, 0, 0, 0, 0, 0, 0, 0, 0, x, 0, 1, 0, 0, 0, 0);
 682 }
 683
 684 into:
 685         movl    $1, %eax
 686         xorps   %xmm0, %xmm0
 687         pinsrw  $2, %eax, %xmm0
 688         movzbl  4(%esp), %eax
 689         pinsrw  $3, %eax, %xmm0
 690         movl    $256, %eax
 691         pinsrw  $7, %eax, %xmm0
 692         ret
 693
 694
 695 gcc-4.2:
 696         subl    $12, %esp
 697         movzbl  16(%esp), %eax
 698         movdqa  LC0, %xmm0
 699         pinsrw  $3, %eax, %xmm0
 700         addl    $12, %esp
 701         ret
 702         .const
 703         .align 4
 704 LC0:
 705         .word   0
 706         .word   0
 707         .word   1
 708         .word   0
 709         .word   0
 710         .word   0
 711         .word   0
 712         .word   256
 713
 714 With SSE4, it should be
 715       movdqa  .LC0(%rip), %xmm0
 716       pinsrb  $6, %edi, %xmm0
 717
 718 //===---------------------------------------------------------------------===//
 719
 720 We should transform a shuffle of two vectors of constants into a single vector
 721 of constants. Also, insertelement of a constant into a vector of constants
 722 should also result in a vector of constants. e.g. 2008-06-25-VecISelBug.ll.
 723
 724 We compiled it to something horrible:
 725
 726         .align  4
 727 LCPI1_1:                                        ##  float
 728         .long   1065353216      ## float 1
 729         .const
 730
 731         .align  4
 732 LCPI1_0:                                        ##  <4 x float>
 733         .space  4
 734         .long   1065353216      ## float 1
 735         .space  4
 736         .long   1065353216      ## float 1
 737         .text
 738         .align  4,0x90
 739         .globl  _t
 740 _t:
 741         xorps   %xmm0, %xmm0
 742         movhps  LCPI1_0, %xmm0
 743         movss   LCPI1_1, %xmm1
 744         movaps  %xmm0, %xmm2
 745         shufps  $2, %xmm1, %xmm2
 746         shufps  $132, %xmm2, %xmm0
 747         movaps  %xmm0, 0
 748
 749 //===---------------------------------------------------------------------===//
 750 rdar://5907648
 751
 752 This function:
 753
 754 float foo(unsigned char x) {
 755   return x;
 756 }
 757
 758 compiles to (x86-32):
 759
 760 define float @foo(i8 zeroext  %x) nounwind  {
 761         %tmp12 = uitofp i8 %x to float          ; <float> [#uses=1]
 762         ret float %tmp12
 763 }
 764
 765 compiles to:
 766
 767 _foo:
 768         subl    $4, %esp
 769         movzbl  8(%esp), %eax
 770         cvtsi2ss        %eax, %xmm0
 771         movss   %xmm0, (%esp)
 772         flds    (%esp)
 773         addl    $4, %esp
 774         ret
 775
 776 We should be able to use:
 777   cvtsi2ss 8($esp), %xmm0
 778 since we know the stack slot is already zext'd.
 779
 780 //===---------------------------------------------------------------------===//
 781
 782 Consider using movlps instead of movsd to implement (scalar_to_vector (loadf64))
 783 when code size is critical. movlps is slower than movsd on core2 but it's one
 784 byte shorter.
 785
 786 //===---------------------------------------------------------------------===//
 787
 788 We should use a dynamic programming based approach to tell when using FPStack
 789 operations is cheaper than SSE.  SciMark montecarlo contains code like this
 790 for example:
 791
 792 double MonteCarlo_num_flops(int Num_samples) {
 793     return ((double) Num_samples)* 4.0;
 794 }
 795
 796 In fpstack mode, this compiles into:
 797
 798 LCPI1_0:
 799         .long   1082130432      ## float 4.000000e+00
 800 _MonteCarlo_num_flops:
 801         subl    $4, %esp
 802         movl    8(%esp), %eax
 803         movl    %eax, (%esp)
 804         fildl   (%esp)
 805         fmuls   LCPI1_0
 806         addl    $4, %esp
 807         ret
 808
 809 in SSE mode, it compiles into significantly slower code:
 810
 811 _MonteCarlo_num_flops:
 812         subl    $12, %esp
 813         cvtsi2sd        16(%esp), %xmm0
 814         mulsd   LCPI1_0, %xmm0
 815         movsd   %xmm0, (%esp)
 816         fldl    (%esp)
 817         addl    $12, %esp
 818         ret
 819
 820 There are also other cases in scimark where using fpstack is better, it is
 821 cheaper to do fld1 than load from a constant pool for example, so
 822 "load, add 1.0, store" is better done in the fp stack, etc.
 823
 824 //===---------------------------------------------------------------------===//
 825
 826 The X86 backend should be able to if-convert SSE comparisons like "ucomisd" to
 827 "cmpsd".  For example, this code:
 828
 829 double d1(double x) { return x == x ? x : x + x; }
 830
 831 Compiles into:
 832
 833 _d1:
 834         ucomisd %xmm0, %xmm0
 835         jnp     LBB1_2
 836         addsd   %xmm0, %xmm0
 837         ret
 838 LBB1_2:
 839         ret
 840
 841 Also, the 'ret's should be shared.  This is PR6032.
 842
 843 //===---------------------------------------------------------------------===//
 844
 845 These should compile into the same code (PR6214): Perhaps instcombine should
 846 canonicalize the former into the later?
 847
 848 define float @foo(float %x) nounwind {
 849   %t = bitcast float %x to i32
 850   %s = and i32 %t, 2147483647
 851   %d = bitcast i32 %s to float
 852   ret float %d
 853 }
 854
 855 declare float @fabsf(float %n)
 856 define float @bar(float %x) nounwind {
 857   %d = call float @fabsf(float %x)
 858   ret float %d
 859 }
 860
 861 //===---------------------------------------------------------------------===//
 862
 863 This IR (from PR6194):
 864
 865 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"
 866 target triple = "x86_64-apple-darwin10.0.0"
 867
 868 %0 = type { double, double }
 869 %struct.float3 = type { float, float, float }
 870
 871 define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp {
 872 entry:
 873   %tmp18 = extractvalue %0 %0, 0                  ; <double> [#uses=1]
 874   %tmp19 = bitcast double %tmp18 to i64           ; <i64> [#uses=1]
 875   %tmp20 = zext i64 %tmp19 to i128                ; <i128> [#uses=1]
 876   %tmp10 = lshr i128 %tmp20, 32                   ; <i128> [#uses=1]
 877   %tmp11 = trunc i128 %tmp10 to i32               ; <i32> [#uses=1]
 878   %tmp12 = bitcast i32 %tmp11 to float            ; <float> [#uses=1]
 879   %tmp5 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ; <float*> [#uses=1]
 880   store float %tmp12, float* %tmp5
 881   ret void
 882 }
 883
 884 Compiles to:
 885
 886 _test:                                  ## @test
 887         movd    %xmm0, %rax
 888         shrq    $32, %rax
 889         movl    %eax, 4(%rdi)
 890         ret
 891
 892 This would be better kept in the SSE unit by treating XMM0 as a 4xfloat and
 893 doing a shuffle from v[1] to v[0] then a float store.
 894
 895 //===---------------------------------------------------------------------===//
 896
 897 On SSE4 machines, we compile this code:
 898
 899 define <2 x float> @test2(<2 x float> %Q, <2 x float> %R,
 900        <2 x float> *%P) nounwind {
 901   %Z = fadd <2 x float> %Q, %R
 902
 903   store <2 x float> %Z, <2 x float> *%P
 904   ret <2 x float> %Z
 905 }
 906
 907 into:
 908
 909 _test2:                                 ## @test2
 910 ## BB#0:
 911         insertps        $0, %xmm2, %xmm2
 912         insertps        $16, %xmm3, %xmm2
 913         insertps        $0, %xmm0, %xmm3
 914         insertps        $16, %xmm1, %xmm3
 915         addps   %xmm2, %xmm3
 916         movq    %xmm3, (%rdi)
 917         movaps  %xmm3, %xmm0
 918         pshufd  $1, %xmm3, %xmm1
 919                                         ## kill: XMM1<def> XMM1<kill>
 920         ret
 921
 922 The insertps's of $0 are pointless complex copies.
 923
 924 //===---------------------------------------------------------------------===//
 925
 926