lib/Target/X86/README-SSE.txt

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