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 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
 498 any number of 0.0 simultaneously.  Currently we only use it for simple
 499 insertions.
 500
 501 See comments in LowerINSERT_VECTOR_ELT_SSE4.
 502
 503 //===---------------------------------------------------------------------===//
 504
 505 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
 506 Custom.  All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
 507 legal, it'll just take a few extra patterns written in the .td file.
 508
 509 Note: this is not a code quality issue; the custom lowered code happens to be
 510 right, but we shouldn't have to custom lower anything.  This is probably related
 511 to <2 x i64> ops being so bad.
 512
 513 //===---------------------------------------------------------------------===//
 514
 515 LLVM currently generates stack realignment code, when it is not necessary
 516 needed. The problem is that we need to know about stack alignment too early,
 517 before RA runs.
 518
 519 At that point we don't know, whether there will be vector spill, or not.
 520 Stack realignment logic is overly conservative here, but otherwise we can
 521 produce unaligned loads/stores.
 522
 523 Fixing this will require some huge RA changes.
 524
 525 Testcase:
 526 #include <emmintrin.h>
 527
 528 typedef short vSInt16 __attribute__ ((__vector_size__ (16)));
 529
 530 static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,
 531 - 22725, - 12873};;
 532
 533 vSInt16 madd(vSInt16 b)
 534 {
 535     return _mm_madd_epi16(a, b);
 536 }
 537
 538 Generated code (x86-32, linux):
 539 madd:
 540         pushl   %ebp
 541         movl    %esp, %ebp
 542         andl    $-16, %esp
 543         movaps  .LCPI1_0, %xmm1
 544         pmaddwd %xmm1, %xmm0
 545         movl    %ebp, %esp
 546         popl    %ebp
 547         ret
 548
 549 //===---------------------------------------------------------------------===//
 550
 551 Consider:
 552 #include <emmintrin.h>
 553 __m128 foo2 (float x) {
 554  return _mm_set_ps (0, 0, x, 0);
 555 }
 556
 557 In x86-32 mode, we generate this spiffy code:
 558
 559 _foo2:
 560         movss   4(%esp), %xmm0
 561         pshufd  $81, %xmm0, %xmm0
 562         ret
 563
 564 in x86-64 mode, we generate this code, which could be better:
 565
 566 _foo2:
 567         xorps   %xmm1, %xmm1
 568         movss   %xmm0, %xmm1
 569         pshufd  $81, %xmm1, %xmm0
 570         ret
 571
 572 In sse4 mode, we could use insertps to make both better.
 573
 574 Here's another testcase that could use insertps [mem]:
 575
 576 #include <xmmintrin.h>
 577 extern float x2, x3;
 578 __m128 foo1 (float x1, float x4) {
 579  return _mm_set_ps (x2, x1, x3, x4);
 580 }
 581
 582 gcc mainline compiles it to:
 583
 584 foo1:
 585        insertps        $0x10, x2(%rip), %xmm0
 586        insertps        $0x10, x3(%rip), %xmm1
 587        movaps  %xmm1, %xmm2
 588        movlhps %xmm0, %xmm2
 589        movaps  %xmm2, %xmm0
 590        ret
 591
 592 //===---------------------------------------------------------------------===//
 593
 594 We compile vector multiply-by-constant into poor code:
 595
 596 define <4 x i32> @f(<4 x i32> %i) nounwind  {
 597         %A = mul <4 x i32> %i, < i32 10, i32 10, i32 10, i32 10 >
 598         ret <4 x i32> %A
 599 }
 600
 601 On targets without SSE4.1, this compiles into:
 602
 603 LCPI1_0:                                        ##  <4 x i32>
 604         .long   10
 605         .long   10
 606         .long   10
 607         .long   10
 608         .text
 609         .align  4,0x90
 610         .globl  _f
 611 _f:
 612         pshufd  $3, %xmm0, %xmm1
 613         movd    %xmm1, %eax
 614         imull   LCPI1_0+12, %eax
 615         movd    %eax, %xmm1
 616         pshufd  $1, %xmm0, %xmm2
 617         movd    %xmm2, %eax
 618         imull   LCPI1_0+4, %eax
 619         movd    %eax, %xmm2
 620         punpckldq       %xmm1, %xmm2
 621         movd    %xmm0, %eax
 622         imull   LCPI1_0, %eax
 623         movd    %eax, %xmm1
 624         movhlps %xmm0, %xmm0
 625         movd    %xmm0, %eax
 626         imull   LCPI1_0+8, %eax
 627         movd    %eax, %xmm0
 628         punpckldq       %xmm0, %xmm1
 629         movaps  %xmm1, %xmm0
 630         punpckldq       %xmm2, %xmm0
 631         ret
 632
 633 It would be better to synthesize integer vector multiplication by constants
 634 using shifts and adds, pslld and paddd here. And even on targets with SSE4.1,
 635 simple cases such as multiplication by powers of two would be better as
 636 vector shifts than as multiplications.
 637
 638 //===---------------------------------------------------------------------===//
 639
 640 We compile this:
 641
 642 __m128i
 643 foo2 (char x)
 644 {
 645   return _mm_set_epi8 (1, 0, 0, 0, 0, 0, 0, 0, 0, x, 0, 1, 0, 0, 0, 0);
 646 }
 647
 648 into:
 649         movl    $1, %eax
 650         xorps   %xmm0, %xmm0
 651         pinsrw  $2, %eax, %xmm0
 652         movzbl  4(%esp), %eax
 653         pinsrw  $3, %eax, %xmm0
 654         movl    $256, %eax
 655         pinsrw  $7, %eax, %xmm0
 656         ret
 657
 658
 659 gcc-4.2:
 660         subl    $12, %esp
 661         movzbl  16(%esp), %eax
 662         movdqa  LC0, %xmm0
 663         pinsrw  $3, %eax, %xmm0
 664         addl    $12, %esp
 665         ret
 666         .const
 667         .align 4
 668 LC0:
 669         .word   0
 670         .word   0
 671         .word   1
 672         .word   0
 673         .word   0
 674         .word   0
 675         .word   0
 676         .word   256
 677
 678 With SSE4, it should be
 679       movdqa  .LC0(%rip), %xmm0
 680       pinsrb  $6, %edi, %xmm0
 681
 682 //===---------------------------------------------------------------------===//
 683
 684 We should transform a shuffle of two vectors of constants into a single vector
 685 of constants. Also, insertelement of a constant into a vector of constants
 686 should also result in a vector of constants. e.g. 2008-06-25-VecISelBug.ll.
 687
 688 We compiled it to something horrible:
 689
 690         .align  4
 691 LCPI1_1:                                        ##  float
 692         .long   1065353216      ## float 1
 693         .const
 694
 695         .align  4
 696 LCPI1_0:                                        ##  <4 x float>
 697         .space  4
 698         .long   1065353216      ## float 1
 699         .space  4
 700         .long   1065353216      ## float 1
 701         .text
 702         .align  4,0x90
 703         .globl  _t
 704 _t:
 705         xorps   %xmm0, %xmm0
 706         movhps  LCPI1_0, %xmm0
 707         movss   LCPI1_1, %xmm1
 708         movaps  %xmm0, %xmm2
 709         shufps  $2, %xmm1, %xmm2
 710         shufps  $132, %xmm2, %xmm0
 711         movaps  %xmm0, 0
 712
 713 //===---------------------------------------------------------------------===//
 714 rdar://5907648
 715
 716 This function:
 717
 718 float foo(unsigned char x) {
 719   return x;
 720 }
 721
 722 compiles to (x86-32):
 723
 724 define float @foo(i8 zeroext  %x) nounwind  {
 725         %tmp12 = uitofp i8 %x to float          ; <float> [#uses=1]
 726         ret float %tmp12
 727 }
 728
 729 compiles to:
 730
 731 _foo:
 732         subl    $4, %esp
 733         movzbl  8(%esp), %eax
 734         cvtsi2ss        %eax, %xmm0
 735         movss   %xmm0, (%esp)
 736         flds    (%esp)
 737         addl    $4, %esp
 738         ret
 739
 740 We should be able to use:
 741   cvtsi2ss 8($esp), %xmm0
 742 since we know the stack slot is already zext'd.
 743
 744 //===---------------------------------------------------------------------===//
 745
 746 Consider using movlps instead of movsd to implement (scalar_to_vector (loadf64))
 747 when code size is critical. movlps is slower than movsd on core2 but it's one
 748 byte shorter.
 749
 750 //===---------------------------------------------------------------------===//
 751
 752 We should use a dynamic programming based approach to tell when using FPStack
 753 operations is cheaper than SSE.  SciMark montecarlo contains code like this
 754 for example:
 755
 756 double MonteCarlo_num_flops(int Num_samples) {
 757     return ((double) Num_samples)* 4.0;
 758 }
 759
 760 In fpstack mode, this compiles into:
 761
 762 LCPI1_0:
 763         .long   1082130432      ## float 4.000000e+00
 764 _MonteCarlo_num_flops:
 765         subl    $4, %esp
 766         movl    8(%esp), %eax
 767         movl    %eax, (%esp)
 768         fildl   (%esp)
 769         fmuls   LCPI1_0
 770         addl    $4, %esp
 771         ret
 772
 773 in SSE mode, it compiles into significantly slower code:
 774
 775 _MonteCarlo_num_flops:
 776         subl    $12, %esp
 777         cvtsi2sd        16(%esp), %xmm0
 778         mulsd   LCPI1_0, %xmm0
 779         movsd   %xmm0, (%esp)
 780         fldl    (%esp)
 781         addl    $12, %esp
 782         ret
 783
 784 There are also other cases in scimark where using fpstack is better, it is
 785 cheaper to do fld1 than load from a constant pool for example, so
 786 "load, add 1.0, store" is better done in the fp stack, etc.
 787
 788 //===---------------------------------------------------------------------===//
 789
 790 The X86 backend should be able to if-convert SSE comparisons like "ucomisd" to
 791 "cmpsd".  For example, this code:
 792
 793 double d1(double x) { return x == x ? x : x + x; }
 794
 795 Compiles into:
 796
 797 _d1:
 798         ucomisd %xmm0, %xmm0
 799         jnp     LBB1_2
 800         addsd   %xmm0, %xmm0
 801         ret
 802 LBB1_2:
 803         ret
 804
 805 Also, the 'ret's should be shared.  This is PR6032.
 806
 807 //===---------------------------------------------------------------------===//
 808
 809 These should compile into the same code (PR6214): Perhaps instcombine should
 810 canonicalize the former into the later?
 811
 812 define float @foo(float %x) nounwind {
 813   %t = bitcast float %x to i32
 814   %s = and i32 %t, 2147483647
 815   %d = bitcast i32 %s to float
 816   ret float %d
 817 }
 818
 819 declare float @fabsf(float %n)
 820 define float @bar(float %x) nounwind {
 821   %d = call float @fabsf(float %x)
 822   ret float %d
 823 }
 824
 825 //===---------------------------------------------------------------------===//
 826
 827 This IR (from PR6194):
 828
 829 target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
 830 target triple = "x86_64-apple-darwin10.0.0"
 831
 832 %0 = type { double, double }
 833 %struct.float3 = type { float, float, float }
 834
 835 define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp {
 836 entry:
 837   %tmp18 = extractvalue %0 %0, 0                  ; <double> [#uses=1]
 838   %tmp19 = bitcast double %tmp18 to i64           ; <i64> [#uses=1]
 839   %tmp20 = zext i64 %tmp19 to i128                ; <i128> [#uses=1]
 840   %tmp10 = lshr i128 %tmp20, 32                   ; <i128> [#uses=1]
 841   %tmp11 = trunc i128 %tmp10 to i32               ; <i32> [#uses=1]
 842   %tmp12 = bitcast i32 %tmp11 to float            ; <float> [#uses=1]
 843   %tmp5 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ; <float*> [#uses=1]
 844   store float %tmp12, float* %tmp5
 845   ret void
 846 }
 847
 848 Compiles to:
 849
 850 _test:                                  ## @test
 851         movd    %xmm0, %rax
 852         shrq    $32, %rax
 853         movl    %eax, 4(%rdi)
 854         ret
 855
 856 This would be better kept in the SSE unit by treating XMM0 as a 4xfloat and
 857 doing a shuffle from v[1] to v[0] then a float store.
 858
 859 //===---------------------------------------------------------------------===//
 860
 861 On SSE4 machines, we compile this code:
 862
 863 define <2 x float> @test2(<2 x float> %Q, <2 x float> %R,
 864        <2 x float> *%P) nounwind {
 865   %Z = fadd <2 x float> %Q, %R
 866
 867   store <2 x float> %Z, <2 x float> *%P
 868   ret <2 x float> %Z
 869 }
 870
 871 into:
 872
 873 _test2:                                 ## @test2
 874 ## BB#0:
 875         insertps        $0, %xmm2, %xmm2
 876         insertps        $16, %xmm3, %xmm2
 877         insertps        $0, %xmm0, %xmm3
 878         insertps        $16, %xmm1, %xmm3
 879         addps   %xmm2, %xmm3
 880         movq    %xmm3, (%rdi)
 881         movaps  %xmm3, %xmm0
 882         pshufd  $1, %xmm3, %xmm1
 883                                         ## kill: XMM1<def> XMM1<kill>
 884         ret
 885
 886 The insertps's of $0 are pointless complex copies.
 887
 888 //===---------------------------------------------------------------------===//
 889
 890 [UNSAFE FP]
 891
 892 void foo(double, double, double);
 893 void norm(double x, double y, double z) {
 894   double scale = __builtin_sqrt(x*x + y*y + z*z);
 895   foo(x/scale, y/scale, z/scale);
 896 }
 897
 898 We currently generate an sqrtsd and 3 divsd instructions. This is bad, fp div is
 899 slow and not pipelined. In -ffast-math mode we could compute "1.0/scale" first
 900 and emit 3 mulsd in place of the divs. This can be done as a target-independent
 901 transform.
 902
 903 If we're dealing with floats instead of doubles we could even replace the sqrtss
 904 and inversion with an rsqrtss instruction, which computes 1/sqrt faster at the
 905 cost of reduced accuracy.
 906
 907 //===---------------------------------------------------------------------===//
 908
 909 This function should be matched to haddpd when the appropriate CPU is enabled:
 910
 911 #include <x86intrin.h>
 912 double f (__m128d p) {
 913   return p[0] + p[1];
 914 }
 915
 916 similarly, v[0]-v[1] should match to hsubpd, and {v[0]-v[1], w[0]-w[1]} should
 917 turn into hsubpd also.
 918
 919 //===---------------------------------------------------------------------===//
 920
 921 define <2 x i32> @foo(<2 x double> %in) {
 922   %x = fptosi <2 x double> %in to <2 x i32>
 923   ret <2 x i32> %x
 924 }
 925
 926 Should compile into cvttpd2dq instead of being scalarized into 2 cvttsd2si.
 927
 928 //===---------------------------------------------------------------------===//