1 //===---------------------------------------------------------------------===//
2 // Random ideas for the X86 backend.
3 //===---------------------------------------------------------------------===//
5 We should add support for the "movbe" instruction, which does a byte-swapping
6 copy (3-addr bswap + memory support?) This is available on Atom processors.
8 //===---------------------------------------------------------------------===//
10 CodeGen/X86/lea-3.ll:test3 should be a single LEA, not a shift/move. The X86
11 backend knows how to three-addressify this shift, but it appears the register
12 allocator isn't even asking it to do so in this case. We should investigate
13 why this isn't happening, it could have significant impact on other important
14 cases for X86 as well.
16 //===---------------------------------------------------------------------===//
18 This should be one DIV/IDIV instruction, not a libcall:
20 unsigned test(unsigned long long X, unsigned Y) {
24 This can be done trivially with a custom legalizer. What about overflow
25 though? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14224
27 //===---------------------------------------------------------------------===//
29 Improvements to the multiply -> shift/add algorithm:
30 http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01590.html
32 //===---------------------------------------------------------------------===//
34 Improve code like this (occurs fairly frequently, e.g. in LLVM):
35 long long foo(int x) { return 1LL << x; }
37 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01109.html
38 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01128.html
39 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01136.html
41 Another useful one would be ~0ULL >> X and ~0ULL << X.
43 One better solution for 1LL << x is:
52 But that requires good 8-bit subreg support.
54 Also, this might be better. It's an extra shift, but it's one instruction
55 shorter, and doesn't stress 8-bit subreg support.
56 (From http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01148.html,
57 but without the unnecessary and.)
65 64-bit shifts (in general) expand to really bad code. Instead of using
66 cmovs, we should expand to a conditional branch like GCC produces.
68 //===---------------------------------------------------------------------===//
71 _Bool f(_Bool a) { return a!=1; }
78 (Although note that this isn't a legal way to express the code that llvm-gcc
79 currently generates for that function.)
81 //===---------------------------------------------------------------------===//
85 1. Dynamic programming based approach when compile time if not an
87 2. Code duplication (addressing mode) during isel.
88 3. Other ideas from "Register-Sensitive Selection, Duplication, and
89 Sequencing of Instructions".
90 4. Scheduling for reduced register pressure. E.g. "Minimum Register
91 Instruction Sequence Problem: Revisiting Optimal Code Generation for DAGs"
92 and other related papers.
93 http://citeseer.ist.psu.edu/govindarajan01minimum.html
95 //===---------------------------------------------------------------------===//
97 Should we promote i16 to i32 to avoid partial register update stalls?
99 //===---------------------------------------------------------------------===//
101 Leave any_extend as pseudo instruction and hint to register
102 allocator. Delay codegen until post register allocation.
103 Note. any_extend is now turned into an INSERT_SUBREG. We still need to teach
104 the coalescer how to deal with it though.
106 //===---------------------------------------------------------------------===//
108 It appears icc use push for parameter passing. Need to investigate.
110 //===---------------------------------------------------------------------===//
112 Only use inc/neg/not instructions on processors where they are faster than
113 add/sub/xor. They are slower on the P4 due to only updating some processor
116 //===---------------------------------------------------------------------===//
118 The instruction selector sometimes misses folding a load into a compare. The
119 pattern is written as (cmp reg, (load p)). Because the compare isn't
120 commutative, it is not matched with the load on both sides. The dag combiner
121 should be made smart enough to cannonicalize the load into the RHS of a compare
122 when it can invert the result of the compare for free.
124 //===---------------------------------------------------------------------===//
126 How about intrinsics? An example is:
127 *res = _mm_mulhi_epu16(*A, _mm_mul_epu32(*B, *C));
130 pmuludq (%eax), %xmm0
135 The transformation probably requires a X86 specific pass or a DAG combiner
136 target specific hook.
138 //===---------------------------------------------------------------------===//
140 In many cases, LLVM generates code like this:
149 on some processors (which ones?), it is more efficient to do this:
158 Doing this correctly is tricky though, as the xor clobbers the flags.
160 //===---------------------------------------------------------------------===//
162 We should generate bts/btr/etc instructions on targets where they are cheap or
163 when codesize is important. e.g., for:
165 void setbit(int *target, int bit) {
166 *target |= (1 << bit);
168 void clearbit(int *target, int bit) {
169 *target &= ~(1 << bit);
172 //===---------------------------------------------------------------------===//
174 Instead of the following for memset char*, 1, 10:
176 movl $16843009, 4(%edx)
177 movl $16843009, (%edx)
180 It might be better to generate
187 when we can spare a register. It reduces code size.
189 //===---------------------------------------------------------------------===//
191 Evaluate what the best way to codegen sdiv X, (2^C) is. For X/8, we currently
194 define i32 @test1(i32 %X) {
208 GCC knows several different ways to codegen it, one of which is this:
218 which is probably slower, but it's interesting at least :)
220 //===---------------------------------------------------------------------===//
222 We are currently lowering large (1MB+) memmove/memcpy to rep/stosl and rep/movsl
223 We should leave these as libcalls for everything over a much lower threshold,
224 since libc is hand tuned for medium and large mem ops (avoiding RFO for large
225 stores, TLB preheating, etc)
227 //===---------------------------------------------------------------------===//
229 Optimize this into something reasonable:
230 x * copysign(1.0, y) * copysign(1.0, z)
232 //===---------------------------------------------------------------------===//
234 Optimize copysign(x, *y) to use an integer load from y.
236 //===---------------------------------------------------------------------===//
238 The following tests perform worse with LSR:
240 lambda, siod, optimizer-eval, ackermann, hash2, nestedloop, strcat, and Treesor.
242 //===---------------------------------------------------------------------===//
244 Teach the coalescer to coalesce vregs of different register classes. e.g. FR32 /
247 //===---------------------------------------------------------------------===//
249 Adding to the list of cmp / test poor codegen issues:
251 int test(__m128 *A, __m128 *B) {
252 if (_mm_comige_ss(*A, *B))
272 Note the setae, movzbl, cmpl, cmove can be replaced with a single cmovae. There
273 are a number of issues. 1) We are introducing a setcc between the result of the
274 intrisic call and select. 2) The intrinsic is expected to produce a i32 value
275 so a any extend (which becomes a zero extend) is added.
277 We probably need some kind of target DAG combine hook to fix this.
279 //===---------------------------------------------------------------------===//
281 We generate significantly worse code for this than GCC:
282 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
283 http://gcc.gnu.org/bugzilla/attachment.cgi?id=8701
285 There is also one case we do worse on PPC.
287 //===---------------------------------------------------------------------===//
297 imull $3, 4(%esp), %eax
299 Perhaps this is what we really should generate is? Is imull three or four
300 cycles? Note: ICC generates this:
302 leal (%eax,%eax,2), %eax
304 The current instruction priority is based on pattern complexity. The former is
305 more "complex" because it folds a load so the latter will not be emitted.
307 Perhaps we should use AddedComplexity to give LEA32r a higher priority? We
308 should always try to match LEA first since the LEA matching code does some
309 estimate to determine whether the match is profitable.
311 However, if we care more about code size, then imull is better. It's two bytes
312 shorter than movl + leal.
314 On a Pentium M, both variants have the same characteristics with regard
315 to throughput; however, the multiplication has a latency of four cycles, as
316 opposed to two cycles for the movl+lea variant.
318 //===---------------------------------------------------------------------===//
320 __builtin_ffs codegen is messy.
322 int ffs_(unsigned X) { return __builtin_ffs(X); }
345 Another example of __builtin_ffs (use predsimplify to eliminate a select):
347 int foo (unsigned long j) {
349 return __builtin_ffs (j) - 1;
354 //===---------------------------------------------------------------------===//
356 It appears gcc place string data with linkonce linkage in
357 .section __TEXT,__const_coal,coalesced instead of
358 .section __DATA,__const_coal,coalesced.
359 Take a look at darwin.h, there are other Darwin assembler directives that we
362 //===---------------------------------------------------------------------===//
364 define i32 @foo(i32* %a, i32 %t) {
368 cond_true: ; preds = %cond_true, %entry
369 %x.0.0 = phi i32 [ 0, %entry ], [ %tmp9, %cond_true ] ; <i32> [#uses=3]
370 %t_addr.0.0 = phi i32 [ %t, %entry ], [ %tmp7, %cond_true ] ; <i32> [#uses=1]
371 %tmp2 = getelementptr i32* %a, i32 %x.0.0 ; <i32*> [#uses=1]
372 %tmp3 = load i32* %tmp2 ; <i32> [#uses=1]
373 %tmp5 = add i32 %t_addr.0.0, %x.0.0 ; <i32> [#uses=1]
374 %tmp7 = add i32 %tmp5, %tmp3 ; <i32> [#uses=2]
375 %tmp9 = add i32 %x.0.0, 1 ; <i32> [#uses=2]
376 %tmp = icmp sgt i32 %tmp9, 39 ; <i1> [#uses=1]
377 br i1 %tmp, label %bb12, label %cond_true
379 bb12: ; preds = %cond_true
382 is pessimized by -loop-reduce and -indvars
384 //===---------------------------------------------------------------------===//
386 u32 to float conversion improvement:
388 float uint32_2_float( unsigned u ) {
389 float fl = (int) (u & 0xffff);
390 float fh = (int) (u >> 16);
395 00000000 subl $0x04,%esp
396 00000003 movl 0x08(%esp,1),%eax
397 00000007 movl %eax,%ecx
398 00000009 shrl $0x10,%ecx
399 0000000c cvtsi2ss %ecx,%xmm0
400 00000010 andl $0x0000ffff,%eax
401 00000015 cvtsi2ss %eax,%xmm1
402 00000019 mulss 0x00000078,%xmm0
403 00000021 addss %xmm1,%xmm0
404 00000025 movss %xmm0,(%esp,1)
405 0000002a flds (%esp,1)
406 0000002d addl $0x04,%esp
409 //===---------------------------------------------------------------------===//
411 When using fastcc abi, align stack slot of argument of type double on 8 byte
412 boundary to improve performance.
414 //===---------------------------------------------------------------------===//
418 int f(int a, int b) {
419 if (a == 4 || a == 6)
431 //===---------------------------------------------------------------------===//
433 GCC's ix86_expand_int_movcc function (in i386.c) has a ton of interesting
434 simplifications for integer "x cmp y ? a : b". For example, instead of:
437 void f(int X, int Y) {
464 int usesbb(unsigned int a, unsigned int b) {
465 return (a < b ? -1 : 0);
479 movl $4294967295, %ecx
483 //===---------------------------------------------------------------------===//
485 Currently we don't have elimination of redundant stack manipulations. Consider
490 call fastcc void %test1( )
491 call fastcc void %test2( sbyte* cast (void ()* %test1 to sbyte*) )
495 declare fastcc void %test1()
497 declare fastcc void %test2(sbyte*)
500 This currently compiles to:
510 The add\sub pair is really unneeded here.
512 //===---------------------------------------------------------------------===//
514 Consider the expansion of:
516 define i32 @test3(i32 %X) {
517 %tmp1 = urem i32 %X, 255
521 Currently it compiles to:
524 movl $2155905153, %ecx
530 This could be "reassociated" into:
532 movl $2155905153, %eax
536 to avoid the copy. In fact, the existing two-address stuff would do this
537 except that mul isn't a commutative 2-addr instruction. I guess this has
538 to be done at isel time based on the #uses to mul?
540 //===---------------------------------------------------------------------===//
542 Make sure the instruction which starts a loop does not cross a cacheline
543 boundary. This requires knowning the exact length of each machine instruction.
544 That is somewhat complicated, but doable. Example 256.bzip2:
546 In the new trace, the hot loop has an instruction which crosses a cacheline
547 boundary. In addition to potential cache misses, this can't help decoding as I
548 imagine there has to be some kind of complicated decoder reset and realignment
549 to grab the bytes from the next cacheline.
551 532 532 0x3cfc movb (1809(%esp, %esi), %bl <<<--- spans 2 64 byte lines
552 942 942 0x3d03 movl %dh, (1809(%esp, %esi)
553 937 937 0x3d0a incl %esi
554 3 3 0x3d0b cmpb %bl, %dl
555 27 27 0x3d0d jnz 0x000062db <main+11707>
557 //===---------------------------------------------------------------------===//
559 In c99 mode, the preprocessor doesn't like assembly comments like #TRUNCATE.
561 //===---------------------------------------------------------------------===//
563 This could be a single 16-bit load.
566 if ((p[0] == 1) & (p[1] == 2)) return 1;
570 //===---------------------------------------------------------------------===//
572 We should inline lrintf and probably other libc functions.
574 //===---------------------------------------------------------------------===//
576 Start using the flags more. For example, compile:
578 int add_zf(int *x, int y, int a, int b) {
602 int add_zf(int *x, int y, int a, int b) {
626 //===---------------------------------------------------------------------===//
628 These two functions have identical effects:
630 unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return i;}
631 unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
633 We currently compile them to:
641 jne LBB1_2 #UnifiedReturnBlock
645 LBB1_2: #UnifiedReturnBlock
655 leal 1(%ecx,%eax), %eax
658 both of which are inferior to GCC's:
676 //===---------------------------------------------------------------------===//
684 is currently compiled to:
695 It would be better to produce:
704 This can be applied to any no-return function call that takes no arguments etc.
705 Alternatively, the stack save/restore logic could be shrink-wrapped, producing
716 Both are useful in different situations. Finally, it could be shrink-wrapped
717 and tail called, like this:
724 pop %eax # realign stack.
727 Though this probably isn't worth it.
729 //===---------------------------------------------------------------------===//
731 We need to teach the codegen to convert two-address INC instructions to LEA
732 when the flags are dead (likewise dec). For example, on X86-64, compile:
734 int foo(int A, int B) {
753 ;; X's live range extends beyond the shift, so the register allocator
754 ;; cannot coalesce it with Y. Because of this, a copy needs to be
755 ;; emitted before the shift to save the register value before it is
756 ;; clobbered. However, this copy is not needed if the register
757 ;; allocator turns the shift into an LEA. This also occurs for ADD.
759 ; Check that the shift gets turned into an LEA.
760 ; RUN: llvm-as < %s | llc -march=x86 -x86-asm-syntax=intel | \
761 ; RUN: not grep {mov E.X, E.X}
763 @G = external global i32 ; <i32*> [#uses=3]
765 define i32 @test1(i32 %X, i32 %Y) {
766 %Z = add i32 %X, %Y ; <i32> [#uses=1]
767 volatile store i32 %Y, i32* @G
768 volatile store i32 %Z, i32* @G
772 define i32 @test2(i32 %X) {
773 %Z = add i32 %X, 1 ; <i32> [#uses=1]
774 volatile store i32 %Z, i32* @G
778 //===---------------------------------------------------------------------===//
780 Sometimes it is better to codegen subtractions from a constant (e.g. 7-x) with
781 a neg instead of a sub instruction. Consider:
783 int test(char X) { return 7-X; }
785 we currently produce:
792 We would use one fewer register if codegen'd as:
799 Note that this isn't beneficial if the load can be folded into the sub. In
800 this case, we want a sub:
802 int test(int X) { return 7-X; }
808 //===---------------------------------------------------------------------===//
810 Leaf functions that require one 4-byte spill slot have a prolog like this:
816 and an epilog like this:
821 It would be smaller, and potentially faster, to push eax on entry and to
822 pop into a dummy register instead of using addl/subl of esp. Just don't pop
823 into any return registers :)
825 //===---------------------------------------------------------------------===//
827 The X86 backend should fold (branch (or (setcc, setcc))) into multiple
828 branches. We generate really poor code for:
830 double testf(double a) {
831 return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
834 For example, the entry BB is:
839 movsd 24(%esp), %xmm1
844 jne LBB1_5 # UnifiedReturnBlock
848 it would be better to replace the last four instructions with:
854 We also codegen the inner ?: into a diamond:
856 cvtss2sd LCPI1_0(%rip), %xmm2
857 cvtss2sd LCPI1_1(%rip), %xmm3
859 ja LBB1_3 # cond_true
866 We should sink the load into xmm3 into the LBB1_2 block. This should
867 be pretty easy, and will nuke all the copies.
869 //===---------------------------------------------------------------------===//
873 inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
874 { return std::make_pair(a + b, a + b < a); }
875 bool no_overflow(unsigned a, unsigned b)
876 { return !full_add(a, b).second; }
886 FIXME: That code looks wrong; bool return is normally defined as zext.
898 //===---------------------------------------------------------------------===//
900 Re-materialize MOV32r0 etc. with xor instead of changing them to moves if the
901 condition register is dead. xor reg reg is shorter than mov reg, #0.
903 //===---------------------------------------------------------------------===//
905 We aren't matching RMW instructions aggressively
906 enough. Here's a reduced testcase (more in PR1160):
908 define void @test(i32* %huge_ptr, i32* %target_ptr) {
909 %A = load i32* %huge_ptr ; <i32> [#uses=1]
910 %B = load i32* %target_ptr ; <i32> [#uses=1]
911 %C = or i32 %A, %B ; <i32> [#uses=1]
912 store i32 %C, i32* %target_ptr
916 $ llvm-as < t.ll | llc -march=x86-64
924 That should be something like:
931 //===---------------------------------------------------------------------===//
935 bb114.preheader: ; preds = %cond_next94
936 %tmp231232 = sext i16 %tmp62 to i32 ; <i32> [#uses=1]
937 %tmp233 = sub i32 32, %tmp231232 ; <i32> [#uses=1]
938 %tmp245246 = sext i16 %tmp65 to i32 ; <i32> [#uses=1]
939 %tmp252253 = sext i16 %tmp68 to i32 ; <i32> [#uses=1]
940 %tmp254 = sub i32 32, %tmp252253 ; <i32> [#uses=1]
941 %tmp553554 = bitcast i16* %tmp37 to i8* ; <i8*> [#uses=2]
942 %tmp583584 = sext i16 %tmp98 to i32 ; <i32> [#uses=1]
943 %tmp585 = sub i32 32, %tmp583584 ; <i32> [#uses=1]
944 %tmp614615 = sext i16 %tmp101 to i32 ; <i32> [#uses=1]
945 %tmp621622 = sext i16 %tmp104 to i32 ; <i32> [#uses=1]
946 %tmp623 = sub i32 32, %tmp621622 ; <i32> [#uses=1]
951 LBB3_5: # bb114.preheader
952 movswl -68(%ebp), %eax
956 movswl -52(%ebp), %eax
959 movswl -70(%ebp), %eax
962 movswl -50(%ebp), %eax
965 movswl -42(%ebp), %eax
967 movswl -66(%ebp), %eax
971 This appears to be bad because the RA is not folding the store to the stack
972 slot into the movl. The above instructions could be:
977 This seems like a cross between remat and spill folding.
979 This has redundant subtractions of %eax from a stack slot. However, %ecx doesn't
980 change, so we could simply subtract %eax from %ecx first and then use %ecx (or
983 //===---------------------------------------------------------------------===//
987 %tmp659 = icmp slt i16 %tmp654, 0 ; <i1> [#uses=1]
988 br i1 %tmp659, label %cond_true662, label %cond_next715
994 jns LBB4_109 # cond_next715
996 Shark tells us that using %cx in the testw instruction is sub-optimal. It
997 suggests using the 32-bit register (which is what ICC uses).
999 //===---------------------------------------------------------------------===//
1003 void compare (long long foo) {
1004 if (foo < 4294967297LL)
1020 jne .LBB1_2 # UnifiedReturnBlock
1023 .LBB1_2: # UnifiedReturnBlock
1027 (also really horrible code on ppc). This is due to the expand code for 64-bit
1028 compares. GCC produces multiple branches, which is much nicer:
1049 //===---------------------------------------------------------------------===//
1051 Tail call optimization improvements: Tail call optimization currently
1052 pushes all arguments on the top of the stack (their normal place for
1053 non-tail call optimized calls) that source from the callers arguments
1054 or that source from a virtual register (also possibly sourcing from
1056 This is done to prevent overwriting of parameters (see example
1057 below) that might be used later.
1061 int callee(int32, int64);
1062 int caller(int32 arg1, int32 arg2) {
1063 int64 local = arg2 * 2;
1064 return callee(arg2, (int64)local);
1067 [arg1] [!arg2 no longer valid since we moved local onto it]
1071 Moving arg1 onto the stack slot of callee function would overwrite
1074 Possible optimizations:
1077 - Analyse the actual parameters of the callee to see which would
1078 overwrite a caller parameter which is used by the callee and only
1079 push them onto the top of the stack.
1081 int callee (int32 arg1, int32 arg2);
1082 int caller (int32 arg1, int32 arg2) {
1083 return callee(arg1,arg2);
1086 Here we don't need to write any variables to the top of the stack
1087 since they don't overwrite each other.
1089 int callee (int32 arg1, int32 arg2);
1090 int caller (int32 arg1, int32 arg2) {
1091 return callee(arg2,arg1);
1094 Here we need to push the arguments because they overwrite each
1097 //===---------------------------------------------------------------------===//
1102 unsigned long int z = 0;
1113 gcc compiles this to:
1139 jge LBB1_4 # cond_true
1142 addl $4294950912, %ecx
1152 1. LSR should rewrite the first cmp with induction variable %ecx.
1153 2. DAG combiner should fold
1159 //===---------------------------------------------------------------------===//
1161 define i64 @test(double %X) {
1162 %Y = fptosi double %X to i64
1170 movsd 24(%esp), %xmm0
1171 movsd %xmm0, 8(%esp)
1180 This should just fldl directly from the input stack slot.
1182 //===---------------------------------------------------------------------===//
1185 int foo (int x) { return (x & 65535) | 255; }
1187 Should compile into:
1190 movzwl 4(%esp), %eax
1201 //===---------------------------------------------------------------------===//
1203 We're codegen'ing multiply of long longs inefficiently:
1205 unsigned long long LLM(unsigned long long arg1, unsigned long long arg2) {
1209 We compile to (fomit-frame-pointer):
1217 imull 12(%esp), %esi
1219 imull 20(%esp), %ecx
1225 This looks like a scheduling deficiency and lack of remat of the load from
1226 the argument area. ICC apparently produces:
1229 imull 12(%esp), %ecx
1238 Note that it remat'd loads from 4(esp) and 12(esp). See this GCC PR:
1239 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
1241 //===---------------------------------------------------------------------===//
1243 We can fold a store into "zeroing a reg". Instead of:
1246 movl %eax, 124(%esp)
1252 if the flags of the xor are dead.
1254 Likewise, we isel "x<<1" into "add reg,reg". If reg is spilled, this should
1255 be folded into: shl [mem], 1
1257 //===---------------------------------------------------------------------===//
1259 This testcase misses a read/modify/write opportunity (from PR1425):
1261 void vertical_decompose97iH1(int *b0, int *b1, int *b2, int width){
1263 for(i=0; i<width; i++)
1264 b1[i] += (1*(b0[i] + b2[i])+0)>>0;
1267 We compile it down to:
1270 movl (%esi,%edi,4), %ebx
1271 addl (%ecx,%edi,4), %ebx
1272 addl (%edx,%edi,4), %ebx
1273 movl %ebx, (%ecx,%edi,4)
1278 the inner loop should add to the memory location (%ecx,%edi,4), saving
1279 a mov. Something like:
1281 movl (%esi,%edi,4), %ebx
1282 addl (%edx,%edi,4), %ebx
1283 addl %ebx, (%ecx,%edi,4)
1285 Here is another interesting example:
1287 void vertical_compose97iH1(int *b0, int *b1, int *b2, int width){
1289 for(i=0; i<width; i++)
1290 b1[i] -= (1*(b0[i] + b2[i])+0)>>0;
1293 We miss the r/m/w opportunity here by using 2 subs instead of an add+sub[mem]:
1296 movl (%ecx,%edi,4), %ebx
1297 subl (%esi,%edi,4), %ebx
1298 subl (%edx,%edi,4), %ebx
1299 movl %ebx, (%ecx,%edi,4)
1304 Additionally, LSR should rewrite the exit condition of these loops to use
1305 a stride-4 IV, would would allow all the scales in the loop to go away.
1306 This would result in smaller code and more efficient microops.
1308 //===---------------------------------------------------------------------===//
1310 In SSE mode, we turn abs and neg into a load from the constant pool plus a xor
1311 or and instruction, for example:
1313 xorpd LCPI1_0, %xmm2
1315 However, if xmm2 gets spilled, we end up with really ugly code like this:
1318 xorpd LCPI1_0, %xmm0
1321 Since we 'know' that this is a 'neg', we can actually "fold" the spill into
1322 the neg/abs instruction, turning it into an *integer* operation, like this:
1324 xorl 2147483648, [mem+4] ## 2147483648 = (1 << 31)
1326 you could also use xorb, but xorl is less likely to lead to a partial register
1327 stall. Here is a contrived testcase:
1330 void test(double *P) {
1340 //===---------------------------------------------------------------------===//
1342 handling llvm.memory.barrier on pre SSE2 cpus
1345 lock ; mov %esp, %esp
1347 //===---------------------------------------------------------------------===//
1349 The generated code on x86 for checking for signed overflow on a multiply the
1350 obvious way is much longer than it needs to be.
1352 int x(int a, int b) {
1353 long long prod = (long long)a*b;
1354 return prod > 0x7FFFFFFF || prod < (-0x7FFFFFFF-1);
1357 See PR2053 for more details.
1359 //===---------------------------------------------------------------------===//
1361 We should investigate using cdq/ctld (effect: edx = sar eax, 31)
1362 more aggressively; it should cost the same as a move+shift on any modern
1363 processor, but it's a lot shorter. Downside is that it puts more
1364 pressure on register allocation because it has fixed operands.
1367 int abs(int x) {return x < 0 ? -x : x;}
1369 gcc compiles this to the following when using march/mtune=pentium2/3/4/m/etc.:
1377 //===---------------------------------------------------------------------===//
1380 int test(unsigned long a, unsigned long b) { return -(a < b); }
1382 We currently compile this to:
1384 define i32 @test(i32 %a, i32 %b) nounwind {
1385 %tmp3 = icmp ult i32 %a, %b ; <i1> [#uses=1]
1386 %tmp34 = zext i1 %tmp3 to i32 ; <i32> [#uses=1]
1387 %tmp5 = sub i32 0, %tmp34 ; <i32> [#uses=1]
1401 Several deficiencies here. First, we should instcombine zext+neg into sext:
1403 define i32 @test2(i32 %a, i32 %b) nounwind {
1404 %tmp3 = icmp ult i32 %a, %b ; <i1> [#uses=1]
1405 %tmp34 = sext i1 %tmp3 to i32 ; <i32> [#uses=1]
1409 However, before we can do that, we have to fix the bad codegen that we get for
1421 This code should be at least as good as the code above. Once this is fixed, we
1422 can optimize this specific case even more to:
1429 //===---------------------------------------------------------------------===//
1431 Take the following code (from
1432 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16541):
1434 extern unsigned char first_one[65536];
1435 int FirstOnet(unsigned long long arg1)
1438 return (first_one[arg1 >> 48]);
1443 The following code is currently generated:
1448 jb .LBB1_2 # UnifiedReturnBlock
1451 movzbl first_one(%eax), %eax
1453 .LBB1_2: # UnifiedReturnBlock
1457 There are a few possible improvements here:
1458 1. We should be able to eliminate the dead load into %ecx
1459 2. We could change the "movl 8(%esp), %eax" into
1460 "movzwl 10(%esp), %eax"; this lets us change the cmpl
1461 into a testl, which is shorter, and eliminate the shift.
1463 We could also in theory eliminate the branch by using a conditional
1464 for the address of the load, but that seems unlikely to be worthwhile
1467 //===---------------------------------------------------------------------===//
1469 We compile this function:
1471 define i32 @foo(i32 %a, i32 %b, i32 %c, i8 zeroext %d) nounwind {
1473 %tmp2 = icmp eq i8 %d, 0 ; <i1> [#uses=1]
1474 br i1 %tmp2, label %bb7, label %bb
1476 bb: ; preds = %entry
1477 %tmp6 = add i32 %b, %a ; <i32> [#uses=1]
1480 bb7: ; preds = %entry
1481 %tmp10 = sub i32 %a, %c ; <i32> [#uses=1]
1501 The coalescer could coalesce "edx" with "eax" to avoid the movl in LBB1_2
1502 if it commuted the addl in LBB1_1.
1504 //===---------------------------------------------------------------------===//
1511 cvtss2sd LCPI1_0, %xmm1
1513 movsd 176(%esp), %xmm2
1518 mulsd LCPI1_23, %xmm4
1519 addsd LCPI1_24, %xmm4
1521 addsd LCPI1_25, %xmm4
1523 addsd LCPI1_26, %xmm4
1525 addsd LCPI1_27, %xmm4
1527 addsd LCPI1_28, %xmm4
1531 movsd 152(%esp), %xmm1
1533 movsd %xmm1, 152(%esp)
1537 LBB1_16: # bb358.loopexit
1538 movsd 152(%esp), %xmm0
1540 addsd LCPI1_22, %xmm0
1541 movsd %xmm0, 152(%esp)
1543 Rather than spilling the result of the last addsd in the loop, we should have
1544 insert a copy to split the interval (one for the duration of the loop, one
1545 extending to the fall through). The register pressure in the loop isn't high
1546 enough to warrant the spill.
1548 Also check why xmm7 is not used at all in the function.
1550 //===---------------------------------------------------------------------===//
1552 Legalize loses track of the fact that bools are always zero extended when in
1553 memory. This causes us to compile abort_gzip (from 164.gzip) from:
1555 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
1556 target triple = "i386-apple-darwin8"
1557 @in_exit.4870.b = internal global i1 false ; <i1*> [#uses=2]
1558 define fastcc void @abort_gzip() noreturn nounwind {
1560 %tmp.b.i = load i1* @in_exit.4870.b ; <i1> [#uses=1]
1561 br i1 %tmp.b.i, label %bb.i, label %bb4.i
1562 bb.i: ; preds = %entry
1563 tail call void @exit( i32 1 ) noreturn nounwind
1565 bb4.i: ; preds = %entry
1566 store i1 true, i1* @in_exit.4870.b
1567 tail call void @exit( i32 1 ) noreturn nounwind
1570 declare void @exit(i32) noreturn nounwind
1576 movb _in_exit.4870.b, %al
1583 //===---------------------------------------------------------------------===//
1587 int test(int x, int y) {
1599 it would be better to codegen as: x+~y (notl+addl)
1601 //===---------------------------------------------------------------------===//
1605 int foo(const char *str,...)
1607 __builtin_va_list a; int x;
1608 __builtin_va_start(a,str); x = __builtin_va_arg(a,int); __builtin_va_end(a);
1612 gets compiled into this on x86-64:
1614 movaps %xmm7, 160(%rsp)
1615 movaps %xmm6, 144(%rsp)
1616 movaps %xmm5, 128(%rsp)
1617 movaps %xmm4, 112(%rsp)
1618 movaps %xmm3, 96(%rsp)
1619 movaps %xmm2, 80(%rsp)
1620 movaps %xmm1, 64(%rsp)
1621 movaps %xmm0, 48(%rsp)
1628 movq %rax, 192(%rsp)
1629 leaq 208(%rsp), %rax
1630 movq %rax, 184(%rsp)
1633 movl 176(%rsp), %eax
1637 movq 184(%rsp), %rcx
1639 movq %rax, 184(%rsp)
1647 addq 192(%rsp), %rcx
1648 movl %eax, 176(%rsp)
1654 leaq 104(%rsp), %rax
1655 movq %rsi, -80(%rsp)
1657 movq %rax, -112(%rsp)
1658 leaq -88(%rsp), %rax
1659 movq %rax, -104(%rsp)
1663 movq -112(%rsp), %rdx
1671 addq -104(%rsp), %rdx
1673 movl %eax, -120(%rsp)
1678 and it gets compiled into this on x86:
1698 //===---------------------------------------------------------------------===//
1700 Teach tblgen not to check bitconvert source type in some cases. This allows us
1701 to consolidate the following patterns in X86InstrMMX.td:
1703 def : Pat<(v2i32 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1705 (v2i32 (MMX_MOVDQ2Qrr VR128:$src))>;
1706 def : Pat<(v4i16 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1708 (v4i16 (MMX_MOVDQ2Qrr VR128:$src))>;
1709 def : Pat<(v8i8 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1711 (v8i8 (MMX_MOVDQ2Qrr VR128:$src))>;
1713 There are other cases in various td files.
1715 //===---------------------------------------------------------------------===//
1717 Take something like the following on x86-32:
1718 unsigned a(unsigned long long x, unsigned y) {return x % y;}
1720 We currently generate a libcall, but we really shouldn't: the expansion is
1721 shorter and likely faster than the libcall. The expected code is something
1733 A similar code sequence works for division.
1735 //===---------------------------------------------------------------------===//
1737 These should compile to the same code, but the later codegen's to useless
1738 instructions on X86. This may be a trivial dag combine (GCC PR7061):
1740 struct s1 { unsigned char a, b; };
1741 unsigned long f1(struct s1 x) {
1744 struct s2 { unsigned a: 8, b: 8; };
1745 unsigned long f2(struct s2 x) {
1749 //===---------------------------------------------------------------------===//
1751 We currently compile this:
1753 define i32 @func1(i32 %v1, i32 %v2) nounwind {
1755 %t = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %v1, i32 %v2)
1756 %sum = extractvalue {i32, i1} %t, 0
1757 %obit = extractvalue {i32, i1} %t, 1
1758 br i1 %obit, label %overflow, label %normal
1762 call void @llvm.trap()
1765 declare {i32, i1} @llvm.sadd.with.overflow.i32(i32, i32)
1766 declare void @llvm.trap()
1773 jo LBB1_2 ## overflow
1779 it would be nice to produce "into" someday.
1781 //===---------------------------------------------------------------------===//
1785 void vec_mpys1(int y[], const int x[], int scaler) {
1787 for (i = 0; i < 150; i++)
1788 y[i] += (((long long)scaler * (long long)x[i]) >> 31);
1791 Compiles to this loop with GCC 3.x:
1796 shrdl $31, %edx, %eax
1797 addl %eax, (%esi,%ecx,4)
1802 llvm-gcc compiles it to the much uglier:
1806 movl (%eax,%edi,4), %ebx
1815 shldl $1, %eax, %ebx
1817 addl %ebx, (%eax,%edi,4)
1822 //===---------------------------------------------------------------------===//
1824 Test instructions can be eliminated by using EFLAGS values from arithmetic
1825 instructions. This is currently not done for mul, and, or, xor, neg, shl,
1826 sra, srl, shld, shrd, atomic ops, and others. It is also currently not done
1827 for read-modify-write instructions. It is also current not done if the
1828 OF or CF flags are needed.
1830 The shift operators have the complication that when the shift count is
1831 zero, EFLAGS is not set, so they can only subsume a test instruction if
1832 the shift count is known to be non-zero. Also, using the EFLAGS value
1833 from a shift is apparently very slow on some x86 implementations.
1835 In read-modify-write instructions, the root node in the isel match is
1836 the store, and isel has no way for the use of the EFLAGS result of the
1837 arithmetic to be remapped to the new node.
1839 Add and subtract instructions set OF on signed overflow and CF on unsiged
1840 overflow, while test instructions always clear OF and CF. In order to
1841 replace a test with an add or subtract in a situation where OF or CF is
1842 needed, codegen must be able to prove that the operation cannot see
1843 signed or unsigned overflow, respectively.
1845 //===---------------------------------------------------------------------===//
1847 memcpy/memmove do not lower to SSE copies when possible. A silly example is:
1848 define <16 x float> @foo(<16 x float> %A) nounwind {
1849 %tmp = alloca <16 x float>, align 16
1850 %tmp2 = alloca <16 x float>, align 16
1851 store <16 x float> %A, <16 x float>* %tmp
1852 %s = bitcast <16 x float>* %tmp to i8*
1853 %s2 = bitcast <16 x float>* %tmp2 to i8*
1854 call void @llvm.memcpy.i64(i8* %s, i8* %s2, i64 64, i32 16)
1855 %R = load <16 x float>* %tmp2
1859 declare void @llvm.memcpy.i64(i8* nocapture, i8* nocapture, i64, i32) nounwind
1865 movaps %xmm3, 112(%esp)
1866 movaps %xmm2, 96(%esp)
1867 movaps %xmm1, 80(%esp)
1868 movaps %xmm0, 64(%esp)
1870 movl %eax, 124(%esp)
1872 movl %eax, 120(%esp)
1874 <many many more 32-bit copies>
1875 movaps (%esp), %xmm0
1876 movaps 16(%esp), %xmm1
1877 movaps 32(%esp), %xmm2
1878 movaps 48(%esp), %xmm3
1882 On Nehalem, it may even be cheaper to just use movups when unaligned than to
1883 fall back to lower-granularity chunks.
1885 //===---------------------------------------------------------------------===//
1887 Implement processor-specific optimizations for parity with GCC on these
1888 processors. GCC does two optimizations:
1890 1. ix86_pad_returns inserts a noop before ret instructions if immediately
1891 preceeded by a conditional branch or is the target of a jump.
1892 2. ix86_avoid_jump_misspredicts inserts noops in cases where a 16-byte block of
1893 code contains more than 3 branches.
1895 The first one is done for all AMDs, Core2, and "Generic"
1896 The second one is done for: Atom, Pentium Pro, all AMDs, Pentium 4, Nocona,
1897 Core 2, and "Generic"
1899 //===---------------------------------------------------------------------===//