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.
  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 For this:
 386
 387 #include <emmintrin.h>
 388 void test(__m128d *r, __m128d *A, double B) {
 389   *r = _mm_loadl_pd(*A, &B);
 390 }
 391
 392 We generates:
 393
 394         subl $12, %esp
 395         movsd 24(%esp), %xmm0
 396         movsd %xmm0, (%esp)
 397         movl 20(%esp), %eax
 398         movapd (%eax), %xmm0
 399         movlpd (%esp), %xmm0
 400         movl 16(%esp), %eax
 401         movapd %xmm0, (%eax)
 402         addl $12, %esp
 403         ret
 404
 405 icc generates:
 406
 407         movl      4(%esp), %edx                                 #3.6
 408         movl      8(%esp), %eax                                 #3.6
 409         movapd    (%eax), %xmm0                                 #4.22
 410         movlpd    12(%esp), %xmm0                               #4.8
 411         movapd    %xmm0, (%edx)                                 #4.3
 412         ret                                                     #5.1
 413
 414 So icc is smart enough to know that B is in memory so it doesn't load it and
 415 store it back to stack.
 416
 417 This should be fixed by eliminating the llvm.x86.sse2.loadl.pd intrinsic,
 418 lowering it to a load+insertelement instead.  Already match the load+shuffle
 419 as movlpd, so this should be easy.  We already get optimal code for:
 420
 421 define void @test2(<2 x double>* %r, <2 x double>* %A, double %B) {
 422 entry:
 423         %tmp2 = load <2 x double>* %A, align 16
 424         %tmp8 = insertelement <2 x double> %tmp2, double %B, i32 0
 425         store <2 x double> %tmp8, <2 x double>* %r, align 16
 426         ret void
 427 }
 428
 429 //===---------------------------------------------------------------------===//
 430
 431 Consider (PR2108):
 432
 433 #include <xmmintrin.h>
 434 __m128i doload64(unsigned long long x) { return _mm_loadl_epi64(&x);}
 435 __m128i doload64_2(unsigned long long *x) { return _mm_loadl_epi64(x);}
 436
 437 These are very similar routines, but we generate significantly worse code for
 438 the first one on x86-32:
 439
 440 _doload64:
 441         subl    $12, %esp
 442         movl    20(%esp), %eax
 443         movl    %eax, 4(%esp)
 444         movl    16(%esp), %eax
 445         movl    %eax, (%esp)
 446         movsd   (%esp), %xmm0
 447         addl    $12, %esp
 448         ret
 449 _doload64_2:
 450         movl    4(%esp), %eax
 451         movsd   (%eax), %xmm0
 452         ret
 453
 454 The problem is that the argument lowering logic splits the i64 argument into
 455 2x i32 loads early, the f64 insert doesn't match.  Here's a reduced testcase:
 456
 457 define fastcc double @doload64(i64 %x) nounwind  {
 458 entry:
 459         %tmp717 = bitcast i64 %x to double              ; <double> [#uses=1]
 460         ret double %tmp717
 461 }
 462
 463 compiles to:
 464
 465 _doload64:
 466         subl    $12, %esp
 467         movl    20(%esp), %eax
 468         movl    %eax, 4(%esp)
 469         movl    16(%esp), %eax
 470         movl    %eax, (%esp)
 471         movsd   (%esp), %xmm0
 472         addl    $12, %esp
 473         ret
 474
 475 instead of movsd from the stack.
 476
 477 //===---------------------------------------------------------------------===//
 478
 479 __m128d test1( __m128d A, __m128d B) {
 480   return _mm_shuffle_pd(A, B, 0x3);
 481 }
 482
 483 compiles to
 484
 485 shufpd $3, %xmm1, %xmm0
 486
 487 Perhaps it's better to use unpckhpd instead?
 488
 489 unpckhpd %xmm1, %xmm0
 490
 491 Don't know if unpckhpd is faster. But it is shorter.
 492
 493 //===---------------------------------------------------------------------===//
 494
 495 This code generates ugly code, probably due to costs being off or something:
 496
 497 define void @test(float* %P, <4 x float>* %P2 ) {
 498         %xFloat0.688 = load float* %P
 499         %tmp = load <4 x float>* %P2
 500         %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3
 501         store <4 x float> %inFloat3.713, <4 x float>* %P2
 502         ret void
 503 }
 504
 505 Generates:
 506
 507 _test:
 508         movl    8(%esp), %eax
 509         movaps  (%eax), %xmm0
 510         pxor    %xmm1, %xmm1
 511         movaps  %xmm0, %xmm2
 512         shufps  $50, %xmm1, %xmm2
 513         shufps  $132, %xmm2, %xmm0
 514         movaps  %xmm0, (%eax)
 515         ret
 516
 517 Would it be better to generate:
 518
 519 _test:
 520         movl 8(%esp), %ecx
 521         movaps (%ecx), %xmm0
 522         xor %eax, %eax
 523         pinsrw $6, %eax, %xmm0
 524         pinsrw $7, %eax, %xmm0
 525         movaps %xmm0, (%ecx)
 526         ret
 527
 528 ?
 529
 530 //===---------------------------------------------------------------------===//
 531
 532 Some useful information in the Apple Altivec / SSE Migration Guide:
 533
 534 http://developer.apple.com/documentation/Performance/Conceptual/
 535 Accelerate_sse_migration/index.html
 536
 537 e.g. SSE select using and, andnot, or. Various SSE compare translations.
 538
 539 //===---------------------------------------------------------------------===//
 540
 541 Add hooks to commute some CMPP operations.
 542
 543 //===---------------------------------------------------------------------===//
 544
 545 Apply the same transformation that merged four float into a single 128-bit load
 546 to loads from constant pool.
 547
 548 //===---------------------------------------------------------------------===//
 549
 550 Floating point max / min are commutable when -enable-unsafe-fp-path is
 551 specified. We should turn int_x86_sse_max_ss and X86ISD::FMIN etc. into other
 552 nodes which are selected to max / min instructions that are marked commutable.
 553
 554 //===---------------------------------------------------------------------===//
 555
 556 We should compile this:
 557 #include <xmmintrin.h>
 558 typedef union {
 559   int i[4];
 560   float f[4];
 561   __m128 v;
 562 } vector4_t;
 563 void swizzle (const void *a, vector4_t * b, vector4_t * c) {
 564   b->v = _mm_loadl_pi (b->v, (__m64 *) a);
 565   c->v = _mm_loadl_pi (c->v, ((__m64 *) a) + 1);
 566 }
 567
 568 to:
 569
 570 _swizzle:
 571         movl    4(%esp), %eax
 572         movl    8(%esp), %edx
 573         movl    12(%esp), %ecx
 574         movlps  (%eax), %xmm0
 575         movlps  %xmm0, (%edx)
 576         movlps  8(%eax), %xmm0
 577         movlps  %xmm0, (%ecx)
 578         ret
 579
 580 not:
 581
 582 swizzle:
 583         movl 8(%esp), %eax
 584         movaps (%eax), %xmm0
 585         movl 4(%esp), %ecx
 586         movlps (%ecx), %xmm0
 587         movaps %xmm0, (%eax)
 588         movl 12(%esp), %eax
 589         movaps (%eax), %xmm0
 590         movlps 8(%ecx), %xmm0
 591         movaps %xmm0, (%eax)
 592         ret
 593
 594 //===---------------------------------------------------------------------===//
 595
 596 These functions should produce the same code:
 597
 598 #include <emmintrin.h>
 599
 600 typedef long long __m128i __attribute__ ((__vector_size__ (16)));
 601
 602 int foo(__m128i* val) {
 603   return __builtin_ia32_vec_ext_v4si(*val, 1);
 604 }
 605 int bar(__m128i* val) {
 606   union vs {
 607     __m128i *_v;
 608     int* _s;
 609   } v = {val};
 610   return v._s[1];
 611 }
 612
 613 We currently produce (with -m64):
 614
 615 _foo:
 616         pshufd $1, (%rdi), %xmm0
 617         movd %xmm0, %eax
 618         ret
 619 _bar:
 620         movl 4(%rdi), %eax
 621         ret
 622
 623 //===---------------------------------------------------------------------===//
 624
 625 We should materialize vector constants like "all ones" and "signbit" with
 626 code like:
 627
 628      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
 629
 630 and:
 631      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
 632      psrlq   xmm1, 31     ; xmm1 = all 100000000000...
 633
 634 instead of using a load from the constant pool.  The later is important for
 635 ABS/NEG/copysign etc.
 636
 637 //===---------------------------------------------------------------------===//
 638
 639 These functions:
 640
 641 #include <xmmintrin.h>
 642 __m128i a;
 643 void x(unsigned short n) {
 644   a = _mm_slli_epi32 (a, n);
 645 }
 646 void y(unsigned n) {
 647   a = _mm_slli_epi32 (a, n);
 648 }
 649
 650 compile to ( -O3 -static -fomit-frame-pointer):
 651 _x:
 652         movzwl  4(%esp), %eax
 653         movd    %eax, %xmm0
 654         movaps  _a, %xmm1
 655         pslld   %xmm0, %xmm1
 656         movaps  %xmm1, _a
 657         ret
 658 _y:
 659         movd    4(%esp), %xmm0
 660         movaps  _a, %xmm1
 661         pslld   %xmm0, %xmm1
 662         movaps  %xmm1, _a
 663         ret
 664
 665 "y" looks good, but "x" does silly movzwl stuff around into a GPR.  It seems
 666 like movd would be sufficient in both cases as the value is already zero
 667 extended in the 32-bit stack slot IIRC.  For signed short, it should also be
 668 save, as a really-signed value would be undefined for pslld.
 669
 670
 671 //===---------------------------------------------------------------------===//
 672
 673 #include <math.h>
 674 int t1(double d) { return signbit(d); }
 675
 676 This currently compiles to:
 677         subl    $12, %esp
 678         movsd   16(%esp), %xmm0
 679         movsd   %xmm0, (%esp)
 680         movl    4(%esp), %eax
 681         shrl    $31, %eax
 682         addl    $12, %esp
 683         ret
 684
 685 We should use movmskp{s|d} instead.
 686
 687 //===---------------------------------------------------------------------===//
 688
 689 CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
 690 (aligned) vector load.  This functionality has a couple of problems.
 691
 692 1. The code to infer alignment from loads of globals is in the X86 backend,
 693    not the dag combiner.  This is because dagcombine2 needs to be able to see
 694    through the X86ISD::Wrapper node, which DAGCombine can't really do.
 695 2. The code for turning 4 x load into a single vector load is target
 696    independent and should be moved to the dag combiner.
 697 3. The code for turning 4 x load into a vector load can only handle a direct
 698    load from a global or a direct load from the stack.  It should be generalized
 699    to handle any load from P, P+4, P+8, P+12, where P can be anything.
 700 4. The alignment inference code cannot handle loads from globals in non-static
 701    mode because it doesn't look through the extra dyld stub load.  If you try
 702    vec_align.ll without -relocation-model=static, you'll see what I mean.
 703
 704 //===---------------------------------------------------------------------===//
 705
 706 We should lower store(fneg(load p), q) into an integer load+xor+store, which
 707 eliminates a constant pool load.  For example, consider:
 708
 709 define i64 @ccosf(float %z.0, float %z.1) nounwind readonly  {
 710 entry:
 711  %tmp6 = sub float -0.000000e+00, %z.1          ; <float> [#uses=1]
 712  %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly
 713  ret i64 %tmp20
 714 }
 715
 716 This currently compiles to:
 717
 718 LCPI1_0:                                        #  <4 x float>
 719         .long   2147483648      # float -0
 720         .long   2147483648      # float -0
 721         .long   2147483648      # float -0
 722         .long   2147483648      # float -0
 723 _ccosf:
 724         subl    $12, %esp
 725         movss   16(%esp), %xmm0
 726         movss   %xmm0, 4(%esp)
 727         movss   20(%esp), %xmm0
 728         xorps   LCPI1_0, %xmm0
 729         movss   %xmm0, (%esp)
 730         call    L_ccoshf$stub
 731         addl    $12, %esp
 732         ret
 733
 734 Note the load into xmm0, then xor (to negate), then store.  In PIC mode,
 735 this code computes the pic base and does two loads to do the constant pool
 736 load, so the improvement is much bigger.
 737
 738 The tricky part about this xform is that the argument load/store isn't exposed
 739 until post-legalize, and at that point, the fneg has been custom expanded into
 740 an X86 fxor.  This means that we need to handle this case in the x86 backend
 741 instead of in target independent code.
 742
 743 //===---------------------------------------------------------------------===//
 744
 745 Non-SSE4 insert into 16 x i8 is atrociously bad.
 746
 747 //===---------------------------------------------------------------------===//
 748
 749 <2 x i64> extract is substantially worse than <2 x f64>, even if the destination
 750 is memory.
 751
 752 //===---------------------------------------------------------------------===//
 753
 754 SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
 755 sitting between the truncate and the extract.
 756
 757 //===---------------------------------------------------------------------===//
 758
 759 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
 760 any number of 0.0 simultaneously.  Currently we only use it for simple
 761 insertions.
 762
 763 See comments in LowerINSERT_VECTOR_ELT_SSE4.
 764
 765 //===---------------------------------------------------------------------===//
 766
 767 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
 768 Custom.  All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
 769 legal, it'll just take a few extra patterns written in the .td file.
 770
 771 Note: this is not a code quality issue; the custom lowered code happens to be
 772 right, but we shouldn't have to custom lower anything.  This is probably related
 773 to <2 x i64> ops being so bad.
 774
 775 //===---------------------------------------------------------------------===//
 776
 777 'select' on vectors and scalars could be a whole lot better.  We currently
 778 lower them to conditional branches.  On x86-64 for example, we compile this:
 779
 780 double test(double a, double b, double c, double d) { return a<b ? c : d; }
 781
 782 to:
 783
 784 _test:
 785         ucomisd %xmm0, %xmm1
 786         ja      LBB1_2  # entry
 787 LBB1_1: # entry
 788         movapd  %xmm3, %xmm2
 789 LBB1_2: # entry
 790         movapd  %xmm2, %xmm0
 791         ret
 792
 793 instead of:
 794
 795 _test:
 796         cmpltsd %xmm1, %xmm0
 797         andpd   %xmm0, %xmm2
 798         andnpd  %xmm3, %xmm0
 799         orpd    %xmm2, %xmm0
 800         ret
 801
 802 For unpredictable branches, the later is much more efficient.  This should
 803 just be a matter of having scalar sse map to SELECT_CC and custom expanding
 804 or iseling it.
 805
 806 //===---------------------------------------------------------------------===//
 807
 808 Take the following code:
 809
 810 #include <xmmintrin.h>
 811 __m128i doload64(short x) {return _mm_set_epi16(x,x,x,x,x,x,x,x);}
 812
 813 LLVM currently generates the following on x86:
 814 doload64:
 815         movzwl  4(%esp), %eax
 816         movd    %eax, %xmm0
 817         punpcklwd       %xmm0, %xmm0
 818         pshufd  $0, %xmm0, %xmm0
 819         ret
 820
 821 gcc's generated code:
 822 doload64:
 823         movd    4(%esp), %xmm0
 824         punpcklwd       %xmm0, %xmm0
 825         pshufd  $0, %xmm0, %xmm0
 826         ret
 827
 828 LLVM should be able to generate the same thing as gcc.  This looks like it is
 829 just a matter of matching (scalar_to_vector (load x)) to movd.
 830
 831 //===---------------------------------------------------------------------===//