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