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 We should materialize vector constants like "all ones" and "signbit" with 
549 code like:
550
551      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
552
553 and:
554      cmpeqps xmm1, xmm1   ; xmm1 = all-ones
555      psrlq   xmm1, 31     ; xmm1 = all 100000000000...
556
557 instead of using a load from the constant pool.  The later is important for
558 ABS/NEG/copysign etc.
559
560 //===---------------------------------------------------------------------===//
561
562 These functions:
563
564 #include <xmmintrin.h>
565 __m128i a;
566 void x(unsigned short n) {
567   a = _mm_slli_epi32 (a, n);
568 }
569 void y(unsigned n) {
570   a = _mm_slli_epi32 (a, n);
571 }
572
573 compile to ( -O3 -static -fomit-frame-pointer):
574 _x:
575         movzwl  4(%esp), %eax
576         movd    %eax, %xmm0
577         movaps  _a, %xmm1
578         pslld   %xmm0, %xmm1
579         movaps  %xmm1, _a
580         ret
581 _y:
582         movd    4(%esp), %xmm0
583         movaps  _a, %xmm1
584         pslld   %xmm0, %xmm1
585         movaps  %xmm1, _a
586         ret
587
588 "y" looks good, but "x" does silly movzwl stuff around into a GPR.  It seems
589 like movd would be sufficient in both cases as the value is already zero 
590 extended in the 32-bit stack slot IIRC.  For signed short, it should also be
591 save, as a really-signed value would be undefined for pslld.
592
593
594 //===---------------------------------------------------------------------===//
595
596 #include <math.h>
597 int t1(double d) { return signbit(d); }
598
599 This currently compiles to:
600         subl    $12, %esp
601         movsd   16(%esp), %xmm0
602         movsd   %xmm0, (%esp)
603         movl    4(%esp), %eax
604         shrl    $31, %eax
605         addl    $12, %esp
606         ret
607
608 We should use movmskp{s|d} instead.
609
610 //===---------------------------------------------------------------------===//
611
612 CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
613 (aligned) vector load.  This functionality has a couple of problems.
614
615 1. The code to infer alignment from loads of globals is in the X86 backend,
616    not the dag combiner.  This is because dagcombine2 needs to be able to see
617    through the X86ISD::Wrapper node, which DAGCombine can't really do.
618 2. The code for turning 4 x load into a single vector load is target 
619    independent and should be moved to the dag combiner.
620 3. The code for turning 4 x load into a vector load can only handle a direct 
621    load from a global or a direct load from the stack.  It should be generalized
622    to handle any load from P, P+4, P+8, P+12, where P can be anything.
623 4. The alignment inference code cannot handle loads from globals in non-static
624    mode because it doesn't look through the extra dyld stub load.  If you try
625    vec_align.ll without -relocation-model=static, you'll see what I mean.
626
627 //===---------------------------------------------------------------------===//
628
629 We should lower store(fneg(load p), q) into an integer load+xor+store, which
630 eliminates a constant pool load.  For example, consider:
631
632 define i64 @ccosf(float %z.0, float %z.1) nounwind readonly  {
633 entry:
634  %tmp6 = sub float -0.000000e+00, %z.1          ; <float> [#uses=1]
635  %tmp20 = tail call i64 @ccoshf( float %tmp6, float %z.0 ) nounwind readonly
636  ret i64 %tmp20
637 }
638
639 This currently compiles to:
640
641 LCPI1_0:                                        #  <4 x float>
642         .long   2147483648      # float -0
643         .long   2147483648      # float -0
644         .long   2147483648      # float -0
645         .long   2147483648      # float -0
646 _ccosf:
647         subl    $12, %esp
648         movss   16(%esp), %xmm0
649         movss   %xmm0, 4(%esp)
650         movss   20(%esp), %xmm0
651         xorps   LCPI1_0, %xmm0
652         movss   %xmm0, (%esp)
653         call    L_ccoshf$stub
654         addl    $12, %esp
655         ret
656
657 Note the load into xmm0, then xor (to negate), then store.  In PIC mode,
658 this code computes the pic base and does two loads to do the constant pool 
659 load, so the improvement is much bigger.
660
661 The tricky part about this xform is that the argument load/store isn't exposed
662 until post-legalize, and at that point, the fneg has been custom expanded into 
663 an X86 fxor.  This means that we need to handle this case in the x86 backend
664 instead of in target independent code.
665
666 //===---------------------------------------------------------------------===//
667
668 Non-SSE4 insert into 16 x i8 is atrociously bad.
669
670 //===---------------------------------------------------------------------===//
671
672 <2 x i64> extract is substantially worse than <2 x f64>, even if the destination
673 is memory.
674
675 //===---------------------------------------------------------------------===//
676
677 SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
678 sitting between the truncate and the extract.
679
680 //===---------------------------------------------------------------------===//
681
682 INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
683 any number of 0.0 simultaneously.  Currently we only use it for simple
684 insertions.
685
686 See comments in LowerINSERT_VECTOR_ELT_SSE4.
687
688 //===---------------------------------------------------------------------===//
689
690 On a random note, SSE2 should declare insert/extract of 2 x f64 as legal, not
691 Custom.  All combinations of insert/extract reg-reg, reg-mem, and mem-reg are
692 legal, it'll just take a few extra patterns written in the .td file.
693
694 Note: this is not a code quality issue; the custom lowered code happens to be
695 right, but we shouldn't have to custom lower anything.  This is probably related
696 to <2 x i64> ops being so bad.
697
698 //===---------------------------------------------------------------------===//
699
700 'select' on vectors and scalars could be a whole lot better.  We currently 
701 lower them to conditional branches.  On x86-64 for example, we compile this:
702
703 double test(double a, double b, double c, double d) { return a<b ? c : d; }
704
705 to:
706
707 _test:
708         ucomisd %xmm0, %xmm1
709         ja      LBB1_2  # entry
710 LBB1_1: # entry
711         movapd  %xmm3, %xmm2
712 LBB1_2: # entry
713         movapd  %xmm2, %xmm0
714         ret
715
716 instead of:
717
718 _test:
719         cmpltsd %xmm1, %xmm0
720         andpd   %xmm0, %xmm2
721         andnpd  %xmm3, %xmm0
722         orpd    %xmm2, %xmm0
723         ret
724
725 For unpredictable branches, the later is much more efficient.  This should
726 just be a matter of having scalar sse map to SELECT_CC and custom expanding
727 or iseling it.
728
729 //===---------------------------------------------------------------------===//
730
731 LLVM currently generates stack realignment code, when it is not necessary
732 needed. The problem is that we need to know about stack alignment too early,
733 before RA runs.
734
735 At that point we don't know, whether there will be vector spill, or not.
736 Stack realignment logic is overly conservative here, but otherwise we can
737 produce unaligned loads/stores.
738
739 Fixing this will require some huge RA changes.
740
741 Testcase:
742 #include <emmintrin.h>
743
744 typedef short vSInt16 __attribute__ ((__vector_size__ (16)));
745
746 static const vSInt16 a = {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,
747 - 22725, - 12873};;
748
749 vSInt16 madd(vSInt16 b)
750 {
751     return _mm_madd_epi16(a, b);
752 }
753
754 Generated code (x86-32, linux):
755 madd:
756         pushl   %ebp
757         movl    %esp, %ebp
758         andl    $-16, %esp
759         movaps  .LCPI1_0, %xmm1
760         pmaddwd %xmm1, %xmm0
761         movl    %ebp, %esp
762         popl    %ebp
763         ret
764
765 //===---------------------------------------------------------------------===//
766
767 Consider:
768 #include <emmintrin.h> 
769 __m128 foo2 (float x) {
770  return _mm_set_ps (0, 0, x, 0);
771 }
772
773 In x86-32 mode, we generate this spiffy code:
774
775 _foo2:
776         movss   4(%esp), %xmm0
777         pshufd  $81, %xmm0, %xmm0
778         ret
779
780 in x86-64 mode, we generate this code, which could be better:
781
782 _foo2:
783         xorps   %xmm1, %xmm1
784         movss   %xmm0, %xmm1
785         pshufd  $81, %xmm1, %xmm0
786         ret
787
788 In sse4 mode, we could use insertps to make both better.
789
790 Here's another testcase that could use insertps [mem]:
791
792 #include <xmmintrin.h>
793 extern float x2, x3;
794 __m128 foo1 (float x1, float x4) {
795  return _mm_set_ps (x2, x1, x3, x4);
796 }
797
798 gcc mainline compiles it to:
799
800 foo1:
801        insertps        $0x10, x2(%rip), %xmm0
802        insertps        $0x10, x3(%rip), %xmm1
803        movaps  %xmm1, %xmm2
804        movlhps %xmm0, %xmm2
805        movaps  %xmm2, %xmm0
806        ret
807
808 //===---------------------------------------------------------------------===//
809