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 //===---------------------------------------------------------------------===//
72 1. Dynamic programming based approach when compile time if not an
74 2. Code duplication (addressing mode) during isel.
75 3. Other ideas from "Register-Sensitive Selection, Duplication, and
76 Sequencing of Instructions".
77 4. Scheduling for reduced register pressure. E.g. "Minimum Register
78 Instruction Sequence Problem: Revisiting Optimal Code Generation for DAGs"
79 and other related papers.
80 http://citeseer.ist.psu.edu/govindarajan01minimum.html
82 //===---------------------------------------------------------------------===//
84 Should we promote i16 to i32 to avoid partial register update stalls?
86 //===---------------------------------------------------------------------===//
88 Leave any_extend as pseudo instruction and hint to register
89 allocator. Delay codegen until post register allocation.
90 Note. any_extend is now turned into an INSERT_SUBREG. We still need to teach
91 the coalescer how to deal with it though.
93 //===---------------------------------------------------------------------===//
95 It appears icc use push for parameter passing. Need to investigate.
97 //===---------------------------------------------------------------------===//
102 void bar(int x, int *P) {
117 Instead of doing an explicit test, we can use the flags off the sar. This
118 occurs in a bigger testcase like this, which is pretty common:
121 int test1(std::vector<int> &X) {
123 for (long i = 0, e = X.size(); i != e; ++i)
128 //===---------------------------------------------------------------------===//
130 Only use inc/neg/not instructions on processors where they are faster than
131 add/sub/xor. They are slower on the P4 due to only updating some processor
134 //===---------------------------------------------------------------------===//
136 The instruction selector sometimes misses folding a load into a compare. The
137 pattern is written as (cmp reg, (load p)). Because the compare isn't
138 commutative, it is not matched with the load on both sides. The dag combiner
139 should be made smart enough to cannonicalize the load into the RHS of a compare
140 when it can invert the result of the compare for free.
142 //===---------------------------------------------------------------------===//
144 In many cases, LLVM generates code like this:
153 on some processors (which ones?), it is more efficient to do this:
162 Doing this correctly is tricky though, as the xor clobbers the flags.
164 //===---------------------------------------------------------------------===//
166 We should generate bts/btr/etc instructions on targets where they are cheap or
167 when codesize is important. e.g., for:
169 void setbit(int *target, int bit) {
170 *target |= (1 << bit);
172 void clearbit(int *target, int bit) {
173 *target &= ~(1 << bit);
176 //===---------------------------------------------------------------------===//
178 Instead of the following for memset char*, 1, 10:
180 movl $16843009, 4(%edx)
181 movl $16843009, (%edx)
184 It might be better to generate
191 when we can spare a register. It reduces code size.
193 //===---------------------------------------------------------------------===//
195 Evaluate what the best way to codegen sdiv X, (2^C) is. For X/8, we currently
198 define i32 @test1(i32 %X) {
212 GCC knows several different ways to codegen it, one of which is this:
222 which is probably slower, but it's interesting at least :)
224 //===---------------------------------------------------------------------===//
226 We are currently lowering large (1MB+) memmove/memcpy to rep/stosl and rep/movsl
227 We should leave these as libcalls for everything over a much lower threshold,
228 since libc is hand tuned for medium and large mem ops (avoiding RFO for large
229 stores, TLB preheating, etc)
231 //===---------------------------------------------------------------------===//
233 Optimize this into something reasonable:
234 x * copysign(1.0, y) * copysign(1.0, z)
236 //===---------------------------------------------------------------------===//
238 Optimize copysign(x, *y) to use an integer load from y.
240 //===---------------------------------------------------------------------===//
242 The following tests perform worse with LSR:
244 lambda, siod, optimizer-eval, ackermann, hash2, nestedloop, strcat, and Treesor.
246 //===---------------------------------------------------------------------===//
248 Adding to the list of cmp / test poor codegen issues:
250 int test(__m128 *A, __m128 *B) {
251 if (_mm_comige_ss(*A, *B))
271 Note the setae, movzbl, cmpl, cmove can be replaced with a single cmovae. There
272 are a number of issues. 1) We are introducing a setcc between the result of the
273 intrisic call and select. 2) The intrinsic is expected to produce a i32 value
274 so a any extend (which becomes a zero extend) is added.
276 We probably need some kind of target DAG combine hook to fix this.
278 //===---------------------------------------------------------------------===//
280 We generate significantly worse code for this than GCC:
281 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
282 http://gcc.gnu.org/bugzilla/attachment.cgi?id=8701
284 There is also one case we do worse on PPC.
286 //===---------------------------------------------------------------------===//
296 imull $3, 4(%esp), %eax
298 Perhaps this is what we really should generate is? Is imull three or four
299 cycles? Note: ICC generates this:
301 leal (%eax,%eax,2), %eax
303 The current instruction priority is based on pattern complexity. The former is
304 more "complex" because it folds a load so the latter will not be emitted.
306 Perhaps we should use AddedComplexity to give LEA32r a higher priority? We
307 should always try to match LEA first since the LEA matching code does some
308 estimate to determine whether the match is profitable.
310 However, if we care more about code size, then imull is better. It's two bytes
311 shorter than movl + leal.
313 On a Pentium M, both variants have the same characteristics with regard
314 to throughput; however, the multiplication has a latency of four cycles, as
315 opposed to two cycles for the movl+lea variant.
317 //===---------------------------------------------------------------------===//
319 __builtin_ffs codegen is messy.
321 int ffs_(unsigned X) { return __builtin_ffs(X); }
344 Another example of __builtin_ffs (use predsimplify to eliminate a select):
346 int foo (unsigned long j) {
348 return __builtin_ffs (j) - 1;
353 //===---------------------------------------------------------------------===//
355 It appears gcc place string data with linkonce linkage in
356 .section __TEXT,__const_coal,coalesced instead of
357 .section __DATA,__const_coal,coalesced.
358 Take a look at darwin.h, there are other Darwin assembler directives that we
361 //===---------------------------------------------------------------------===//
363 define i32 @foo(i32* %a, i32 %t) {
367 cond_true: ; preds = %cond_true, %entry
368 %x.0.0 = phi i32 [ 0, %entry ], [ %tmp9, %cond_true ] ; <i32> [#uses=3]
369 %t_addr.0.0 = phi i32 [ %t, %entry ], [ %tmp7, %cond_true ] ; <i32> [#uses=1]
370 %tmp2 = getelementptr i32* %a, i32 %x.0.0 ; <i32*> [#uses=1]
371 %tmp3 = load i32* %tmp2 ; <i32> [#uses=1]
372 %tmp5 = add i32 %t_addr.0.0, %x.0.0 ; <i32> [#uses=1]
373 %tmp7 = add i32 %tmp5, %tmp3 ; <i32> [#uses=2]
374 %tmp9 = add i32 %x.0.0, 1 ; <i32> [#uses=2]
375 %tmp = icmp sgt i32 %tmp9, 39 ; <i1> [#uses=1]
376 br i1 %tmp, label %bb12, label %cond_true
378 bb12: ; preds = %cond_true
381 is pessimized by -loop-reduce and -indvars
383 //===---------------------------------------------------------------------===//
385 u32 to float conversion improvement:
387 float uint32_2_float( unsigned u ) {
388 float fl = (int) (u & 0xffff);
389 float fh = (int) (u >> 16);
394 00000000 subl $0x04,%esp
395 00000003 movl 0x08(%esp,1),%eax
396 00000007 movl %eax,%ecx
397 00000009 shrl $0x10,%ecx
398 0000000c cvtsi2ss %ecx,%xmm0
399 00000010 andl $0x0000ffff,%eax
400 00000015 cvtsi2ss %eax,%xmm1
401 00000019 mulss 0x00000078,%xmm0
402 00000021 addss %xmm1,%xmm0
403 00000025 movss %xmm0,(%esp,1)
404 0000002a flds (%esp,1)
405 0000002d addl $0x04,%esp
408 //===---------------------------------------------------------------------===//
410 When using fastcc abi, align stack slot of argument of type double on 8 byte
411 boundary to improve performance.
413 //===---------------------------------------------------------------------===//
415 GCC's ix86_expand_int_movcc function (in i386.c) has a ton of interesting
416 simplifications for integer "x cmp y ? a : b".
418 //===---------------------------------------------------------------------===//
420 Consider the expansion of:
422 define i32 @test3(i32 %X) {
423 %tmp1 = urem i32 %X, 255
427 Currently it compiles to:
430 movl $2155905153, %ecx
436 This could be "reassociated" into:
438 movl $2155905153, %eax
442 to avoid the copy. In fact, the existing two-address stuff would do this
443 except that mul isn't a commutative 2-addr instruction. I guess this has
444 to be done at isel time based on the #uses to mul?
446 //===---------------------------------------------------------------------===//
448 Make sure the instruction which starts a loop does not cross a cacheline
449 boundary. This requires knowning the exact length of each machine instruction.
450 That is somewhat complicated, but doable. Example 256.bzip2:
452 In the new trace, the hot loop has an instruction which crosses a cacheline
453 boundary. In addition to potential cache misses, this can't help decoding as I
454 imagine there has to be some kind of complicated decoder reset and realignment
455 to grab the bytes from the next cacheline.
457 532 532 0x3cfc movb (1809(%esp, %esi), %bl <<<--- spans 2 64 byte lines
458 942 942 0x3d03 movl %dh, (1809(%esp, %esi)
459 937 937 0x3d0a incl %esi
460 3 3 0x3d0b cmpb %bl, %dl
461 27 27 0x3d0d jnz 0x000062db <main+11707>
463 //===---------------------------------------------------------------------===//
465 In c99 mode, the preprocessor doesn't like assembly comments like #TRUNCATE.
467 //===---------------------------------------------------------------------===//
469 This could be a single 16-bit load.
472 if ((p[0] == 1) & (p[1] == 2)) return 1;
476 //===---------------------------------------------------------------------===//
478 We should inline lrintf and probably other libc functions.
480 //===---------------------------------------------------------------------===//
482 Use the FLAGS values from arithmetic instructions more. For example, compile:
484 int add_zf(int *x, int y, int a, int b) {
506 As another example, compile function f2 in test/CodeGen/X86/cmp-test.ll
507 without a test instruction.
509 //===---------------------------------------------------------------------===//
511 These two functions have identical effects:
513 unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return i;}
514 unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
516 We currently compile them to:
524 jne LBB1_2 #UnifiedReturnBlock
528 LBB1_2: #UnifiedReturnBlock
538 leal 1(%ecx,%eax), %eax
541 both of which are inferior to GCC's:
559 //===---------------------------------------------------------------------===//
567 is currently compiled to:
578 It would be better to produce:
587 This can be applied to any no-return function call that takes no arguments etc.
588 Alternatively, the stack save/restore logic could be shrink-wrapped, producing
599 Both are useful in different situations. Finally, it could be shrink-wrapped
600 and tail called, like this:
607 pop %eax # realign stack.
610 Though this probably isn't worth it.
612 //===---------------------------------------------------------------------===//
614 Sometimes it is better to codegen subtractions from a constant (e.g. 7-x) with
615 a neg instead of a sub instruction. Consider:
617 int test(char X) { return 7-X; }
619 we currently produce:
626 We would use one fewer register if codegen'd as:
633 Note that this isn't beneficial if the load can be folded into the sub. In
634 this case, we want a sub:
636 int test(int X) { return 7-X; }
642 //===---------------------------------------------------------------------===//
644 Leaf functions that require one 4-byte spill slot have a prolog like this:
650 and an epilog like this:
655 It would be smaller, and potentially faster, to push eax on entry and to
656 pop into a dummy register instead of using addl/subl of esp. Just don't pop
657 into any return registers :)
659 //===---------------------------------------------------------------------===//
661 The X86 backend should fold (branch (or (setcc, setcc))) into multiple
662 branches. We generate really poor code for:
664 double testf(double a) {
665 return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
668 For example, the entry BB is:
673 movsd 24(%esp), %xmm1
678 jne LBB1_5 # UnifiedReturnBlock
682 it would be better to replace the last four instructions with:
688 We also codegen the inner ?: into a diamond:
690 cvtss2sd LCPI1_0(%rip), %xmm2
691 cvtss2sd LCPI1_1(%rip), %xmm3
693 ja LBB1_3 # cond_true
700 We should sink the load into xmm3 into the LBB1_2 block. This should
701 be pretty easy, and will nuke all the copies.
703 //===---------------------------------------------------------------------===//
707 inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
708 { return std::make_pair(a + b, a + b < a); }
709 bool no_overflow(unsigned a, unsigned b)
710 { return !full_add(a, b).second; }
720 FIXME: That code looks wrong; bool return is normally defined as zext.
732 //===---------------------------------------------------------------------===//
736 bb114.preheader: ; preds = %cond_next94
737 %tmp231232 = sext i16 %tmp62 to i32 ; <i32> [#uses=1]
738 %tmp233 = sub i32 32, %tmp231232 ; <i32> [#uses=1]
739 %tmp245246 = sext i16 %tmp65 to i32 ; <i32> [#uses=1]
740 %tmp252253 = sext i16 %tmp68 to i32 ; <i32> [#uses=1]
741 %tmp254 = sub i32 32, %tmp252253 ; <i32> [#uses=1]
742 %tmp553554 = bitcast i16* %tmp37 to i8* ; <i8*> [#uses=2]
743 %tmp583584 = sext i16 %tmp98 to i32 ; <i32> [#uses=1]
744 %tmp585 = sub i32 32, %tmp583584 ; <i32> [#uses=1]
745 %tmp614615 = sext i16 %tmp101 to i32 ; <i32> [#uses=1]
746 %tmp621622 = sext i16 %tmp104 to i32 ; <i32> [#uses=1]
747 %tmp623 = sub i32 32, %tmp621622 ; <i32> [#uses=1]
752 LBB3_5: # bb114.preheader
753 movswl -68(%ebp), %eax
757 movswl -52(%ebp), %eax
760 movswl -70(%ebp), %eax
763 movswl -50(%ebp), %eax
766 movswl -42(%ebp), %eax
768 movswl -66(%ebp), %eax
772 This appears to be bad because the RA is not folding the store to the stack
773 slot into the movl. The above instructions could be:
778 This seems like a cross between remat and spill folding.
780 This has redundant subtractions of %eax from a stack slot. However, %ecx doesn't
781 change, so we could simply subtract %eax from %ecx first and then use %ecx (or
784 //===---------------------------------------------------------------------===//
788 %tmp659 = icmp slt i16 %tmp654, 0 ; <i1> [#uses=1]
789 br i1 %tmp659, label %cond_true662, label %cond_next715
795 jns LBB4_109 # cond_next715
797 Shark tells us that using %cx in the testw instruction is sub-optimal. It
798 suggests using the 32-bit register (which is what ICC uses).
800 //===---------------------------------------------------------------------===//
804 void compare (long long foo) {
805 if (foo < 4294967297LL)
821 jne .LBB1_2 # UnifiedReturnBlock
824 .LBB1_2: # UnifiedReturnBlock
828 (also really horrible code on ppc). This is due to the expand code for 64-bit
829 compares. GCC produces multiple branches, which is much nicer:
850 //===---------------------------------------------------------------------===//
852 Tail call optimization improvements: Tail call optimization currently
853 pushes all arguments on the top of the stack (their normal place for
854 non-tail call optimized calls) that source from the callers arguments
855 or that source from a virtual register (also possibly sourcing from
857 This is done to prevent overwriting of parameters (see example
858 below) that might be used later.
862 int callee(int32, int64);
863 int caller(int32 arg1, int32 arg2) {
864 int64 local = arg2 * 2;
865 return callee(arg2, (int64)local);
868 [arg1] [!arg2 no longer valid since we moved local onto it]
872 Moving arg1 onto the stack slot of callee function would overwrite
875 Possible optimizations:
878 - Analyse the actual parameters of the callee to see which would
879 overwrite a caller parameter which is used by the callee and only
880 push them onto the top of the stack.
882 int callee (int32 arg1, int32 arg2);
883 int caller (int32 arg1, int32 arg2) {
884 return callee(arg1,arg2);
887 Here we don't need to write any variables to the top of the stack
888 since they don't overwrite each other.
890 int callee (int32 arg1, int32 arg2);
891 int caller (int32 arg1, int32 arg2) {
892 return callee(arg2,arg1);
895 Here we need to push the arguments because they overwrite each
898 //===---------------------------------------------------------------------===//
903 unsigned long int z = 0;
914 gcc compiles this to:
940 jge LBB1_4 # cond_true
943 addl $4294950912, %ecx
953 1. LSR should rewrite the first cmp with induction variable %ecx.
954 2. DAG combiner should fold
960 //===---------------------------------------------------------------------===//
962 define i64 @test(double %X) {
963 %Y = fptosi double %X to i64
971 movsd 24(%esp), %xmm0
981 This should just fldl directly from the input stack slot.
983 //===---------------------------------------------------------------------===//
986 int foo (int x) { return (x & 65535) | 255; }
1002 //===---------------------------------------------------------------------===//
1004 We're codegen'ing multiply of long longs inefficiently:
1006 unsigned long long LLM(unsigned long long arg1, unsigned long long arg2) {
1010 We compile to (fomit-frame-pointer):
1018 imull 12(%esp), %esi
1020 imull 20(%esp), %ecx
1026 This looks like a scheduling deficiency and lack of remat of the load from
1027 the argument area. ICC apparently produces:
1030 imull 12(%esp), %ecx
1039 Note that it remat'd loads from 4(esp) and 12(esp). See this GCC PR:
1040 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
1042 //===---------------------------------------------------------------------===//
1044 We can fold a store into "zeroing a reg". Instead of:
1047 movl %eax, 124(%esp)
1053 if the flags of the xor are dead.
1055 Likewise, we isel "x<<1" into "add reg,reg". If reg is spilled, this should
1056 be folded into: shl [mem], 1
1058 //===---------------------------------------------------------------------===//
1060 In SSE mode, we turn abs and neg into a load from the constant pool plus a xor
1061 or and instruction, for example:
1063 xorpd LCPI1_0, %xmm2
1065 However, if xmm2 gets spilled, we end up with really ugly code like this:
1068 xorpd LCPI1_0, %xmm0
1071 Since we 'know' that this is a 'neg', we can actually "fold" the spill into
1072 the neg/abs instruction, turning it into an *integer* operation, like this:
1074 xorl 2147483648, [mem+4] ## 2147483648 = (1 << 31)
1076 you could also use xorb, but xorl is less likely to lead to a partial register
1077 stall. Here is a contrived testcase:
1080 void test(double *P) {
1090 //===---------------------------------------------------------------------===//
1092 The generated code on x86 for checking for signed overflow on a multiply the
1093 obvious way is much longer than it needs to be.
1095 int x(int a, int b) {
1096 long long prod = (long long)a*b;
1097 return prod > 0x7FFFFFFF || prod < (-0x7FFFFFFF-1);
1100 See PR2053 for more details.
1102 //===---------------------------------------------------------------------===//
1104 We should investigate using cdq/ctld (effect: edx = sar eax, 31)
1105 more aggressively; it should cost the same as a move+shift on any modern
1106 processor, but it's a lot shorter. Downside is that it puts more
1107 pressure on register allocation because it has fixed operands.
1110 int abs(int x) {return x < 0 ? -x : x;}
1112 gcc compiles this to the following when using march/mtune=pentium2/3/4/m/etc.:
1120 //===---------------------------------------------------------------------===//
1122 Take the following code (from
1123 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16541):
1125 extern unsigned char first_one[65536];
1126 int FirstOnet(unsigned long long arg1)
1129 return (first_one[arg1 >> 48]);
1134 The following code is currently generated:
1139 jb .LBB1_2 # UnifiedReturnBlock
1142 movzbl first_one(%eax), %eax
1144 .LBB1_2: # UnifiedReturnBlock
1148 We could change the "movl 8(%esp), %eax" into "movzwl 10(%esp), %eax"; this
1149 lets us change the cmpl into a testl, which is shorter, and eliminate the shift.
1151 //===---------------------------------------------------------------------===//
1153 We compile this function:
1155 define i32 @foo(i32 %a, i32 %b, i32 %c, i8 zeroext %d) nounwind {
1157 %tmp2 = icmp eq i8 %d, 0 ; <i1> [#uses=1]
1158 br i1 %tmp2, label %bb7, label %bb
1160 bb: ; preds = %entry
1161 %tmp6 = add i32 %b, %a ; <i32> [#uses=1]
1164 bb7: ; preds = %entry
1165 %tmp10 = sub i32 %a, %c ; <i32> [#uses=1]
1186 There's an obviously unnecessary movl in .LBB0_2, and we could eliminate a
1187 couple more movls by putting 4(%esp) into %eax instead of %ecx.
1189 //===---------------------------------------------------------------------===//
1196 cvtss2sd LCPI1_0, %xmm1
1198 movsd 176(%esp), %xmm2
1203 mulsd LCPI1_23, %xmm4
1204 addsd LCPI1_24, %xmm4
1206 addsd LCPI1_25, %xmm4
1208 addsd LCPI1_26, %xmm4
1210 addsd LCPI1_27, %xmm4
1212 addsd LCPI1_28, %xmm4
1216 movsd 152(%esp), %xmm1
1218 movsd %xmm1, 152(%esp)
1222 LBB1_16: # bb358.loopexit
1223 movsd 152(%esp), %xmm0
1225 addsd LCPI1_22, %xmm0
1226 movsd %xmm0, 152(%esp)
1228 Rather than spilling the result of the last addsd in the loop, we should have
1229 insert a copy to split the interval (one for the duration of the loop, one
1230 extending to the fall through). The register pressure in the loop isn't high
1231 enough to warrant the spill.
1233 Also check why xmm7 is not used at all in the function.
1235 //===---------------------------------------------------------------------===//
1239 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"
1240 target triple = "i386-apple-darwin8"
1241 @in_exit.4870.b = internal global i1 false ; <i1*> [#uses=2]
1242 define fastcc void @abort_gzip() noreturn nounwind {
1244 %tmp.b.i = load i1* @in_exit.4870.b ; <i1> [#uses=1]
1245 br i1 %tmp.b.i, label %bb.i, label %bb4.i
1246 bb.i: ; preds = %entry
1247 tail call void @exit( i32 1 ) noreturn nounwind
1249 bb4.i: ; preds = %entry
1250 store i1 true, i1* @in_exit.4870.b
1251 tail call void @exit( i32 1 ) noreturn nounwind
1254 declare void @exit(i32) noreturn nounwind
1257 _abort_gzip: ## @abort_gzip
1260 movb _in_exit.4870.b, %al
1264 We somehow miss folding the movb into the cmpb.
1266 //===---------------------------------------------------------------------===//
1270 int test(int x, int y) {
1282 it would be better to codegen as: x+~y (notl+addl)
1284 //===---------------------------------------------------------------------===//
1288 int foo(const char *str,...)
1290 __builtin_va_list a; int x;
1291 __builtin_va_start(a,str); x = __builtin_va_arg(a,int); __builtin_va_end(a);
1295 gets compiled into this on x86-64:
1297 movaps %xmm7, 160(%rsp)
1298 movaps %xmm6, 144(%rsp)
1299 movaps %xmm5, 128(%rsp)
1300 movaps %xmm4, 112(%rsp)
1301 movaps %xmm3, 96(%rsp)
1302 movaps %xmm2, 80(%rsp)
1303 movaps %xmm1, 64(%rsp)
1304 movaps %xmm0, 48(%rsp)
1311 movq %rax, 192(%rsp)
1312 leaq 208(%rsp), %rax
1313 movq %rax, 184(%rsp)
1316 movl 176(%rsp), %eax
1320 movq 184(%rsp), %rcx
1322 movq %rax, 184(%rsp)
1330 addq 192(%rsp), %rcx
1331 movl %eax, 176(%rsp)
1337 leaq 104(%rsp), %rax
1338 movq %rsi, -80(%rsp)
1340 movq %rax, -112(%rsp)
1341 leaq -88(%rsp), %rax
1342 movq %rax, -104(%rsp)
1346 movq -112(%rsp), %rdx
1354 addq -104(%rsp), %rdx
1356 movl %eax, -120(%rsp)
1361 and it gets compiled into this on x86:
1381 //===---------------------------------------------------------------------===//
1383 Teach tblgen not to check bitconvert source type in some cases. This allows us
1384 to consolidate the following patterns in X86InstrMMX.td:
1386 def : Pat<(v2i32 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1388 (v2i32 (MMX_MOVDQ2Qrr VR128:$src))>;
1389 def : Pat<(v4i16 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1391 (v4i16 (MMX_MOVDQ2Qrr VR128:$src))>;
1392 def : Pat<(v8i8 (bitconvert (i64 (vector_extract (v2i64 VR128:$src),
1394 (v8i8 (MMX_MOVDQ2Qrr VR128:$src))>;
1396 There are other cases in various td files.
1398 //===---------------------------------------------------------------------===//
1400 Take something like the following on x86-32:
1401 unsigned a(unsigned long long x, unsigned y) {return x % y;}
1403 We currently generate a libcall, but we really shouldn't: the expansion is
1404 shorter and likely faster than the libcall. The expected code is something
1416 A similar code sequence works for division.
1418 //===---------------------------------------------------------------------===//
1420 These should compile to the same code, but the later codegen's to useless
1421 instructions on X86. This may be a trivial dag combine (GCC PR7061):
1423 struct s1 { unsigned char a, b; };
1424 unsigned long f1(struct s1 x) {
1427 struct s2 { unsigned a: 8, b: 8; };
1428 unsigned long f2(struct s2 x) {
1432 //===---------------------------------------------------------------------===//
1434 We currently compile this:
1436 define i32 @func1(i32 %v1, i32 %v2) nounwind {
1438 %t = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %v1, i32 %v2)
1439 %sum = extractvalue {i32, i1} %t, 0
1440 %obit = extractvalue {i32, i1} %t, 1
1441 br i1 %obit, label %overflow, label %normal
1445 call void @llvm.trap()
1448 declare {i32, i1} @llvm.sadd.with.overflow.i32(i32, i32)
1449 declare void @llvm.trap()
1456 jo LBB1_2 ## overflow
1462 it would be nice to produce "into" someday.
1464 //===---------------------------------------------------------------------===//
1468 void vec_mpys1(int y[], const int x[], int scaler) {
1470 for (i = 0; i < 150; i++)
1471 y[i] += (((long long)scaler * (long long)x[i]) >> 31);
1474 Compiles to this loop with GCC 3.x:
1479 shrdl $31, %edx, %eax
1480 addl %eax, (%esi,%ecx,4)
1485 llvm-gcc compiles it to the much uglier:
1489 movl (%eax,%edi,4), %ebx
1498 shldl $1, %eax, %ebx
1500 addl %ebx, (%eax,%edi,4)
1505 The issue is that we hoist the cast of "scaler" to long long outside of the
1506 loop, the value comes into the loop as two values, and
1507 RegsForValue::getCopyFromRegs doesn't know how to put an AssertSext on the
1508 constructed BUILD_PAIR which represents the cast value.
1510 This can be handled by making CodeGenPrepare sink the cast.
1512 //===---------------------------------------------------------------------===//
1514 Test instructions can be eliminated by using EFLAGS values from arithmetic
1515 instructions. This is currently not done for mul, and, or, xor, neg, shl,
1516 sra, srl, shld, shrd, atomic ops, and others. It is also currently not done
1517 for read-modify-write instructions. It is also current not done if the
1518 OF or CF flags are needed.
1520 The shift operators have the complication that when the shift count is
1521 zero, EFLAGS is not set, so they can only subsume a test instruction if
1522 the shift count is known to be non-zero. Also, using the EFLAGS value
1523 from a shift is apparently very slow on some x86 implementations.
1525 In read-modify-write instructions, the root node in the isel match is
1526 the store, and isel has no way for the use of the EFLAGS result of the
1527 arithmetic to be remapped to the new node.
1529 Add and subtract instructions set OF on signed overflow and CF on unsiged
1530 overflow, while test instructions always clear OF and CF. In order to
1531 replace a test with an add or subtract in a situation where OF or CF is
1532 needed, codegen must be able to prove that the operation cannot see
1533 signed or unsigned overflow, respectively.
1535 //===---------------------------------------------------------------------===//
1537 memcpy/memmove do not lower to SSE copies when possible. A silly example is:
1538 define <16 x float> @foo(<16 x float> %A) nounwind {
1539 %tmp = alloca <16 x float>, align 16
1540 %tmp2 = alloca <16 x float>, align 16
1541 store <16 x float> %A, <16 x float>* %tmp
1542 %s = bitcast <16 x float>* %tmp to i8*
1543 %s2 = bitcast <16 x float>* %tmp2 to i8*
1544 call void @llvm.memcpy.i64(i8* %s, i8* %s2, i64 64, i32 16)
1545 %R = load <16 x float>* %tmp2
1549 declare void @llvm.memcpy.i64(i8* nocapture, i8* nocapture, i64, i32) nounwind
1555 movaps %xmm3, 112(%esp)
1556 movaps %xmm2, 96(%esp)
1557 movaps %xmm1, 80(%esp)
1558 movaps %xmm0, 64(%esp)
1560 movl %eax, 124(%esp)
1562 movl %eax, 120(%esp)
1564 <many many more 32-bit copies>
1565 movaps (%esp), %xmm0
1566 movaps 16(%esp), %xmm1
1567 movaps 32(%esp), %xmm2
1568 movaps 48(%esp), %xmm3
1572 On Nehalem, it may even be cheaper to just use movups when unaligned than to
1573 fall back to lower-granularity chunks.
1575 //===---------------------------------------------------------------------===//
1577 Implement processor-specific optimizations for parity with GCC on these
1578 processors. GCC does two optimizations:
1580 1. ix86_pad_returns inserts a noop before ret instructions if immediately
1581 preceeded by a conditional branch or is the target of a jump.
1582 2. ix86_avoid_jump_misspredicts inserts noops in cases where a 16-byte block of
1583 code contains more than 3 branches.
1585 The first one is done for all AMDs, Core2, and "Generic"
1586 The second one is done for: Atom, Pentium Pro, all AMDs, Pentium 4, Nocona,
1587 Core 2, and "Generic"
1589 //===---------------------------------------------------------------------===//
1592 int a(int x) { return (x & 127) > 31; }
1608 This should definitely be done in instcombine, canonicalizing the range
1609 condition into a != condition. We get this IR:
1611 define i32 @a(i32 %x) nounwind readnone {
1613 %0 = and i32 %x, 127 ; <i32> [#uses=1]
1614 %1 = icmp ugt i32 %0, 31 ; <i1> [#uses=1]
1615 %2 = zext i1 %1 to i32 ; <i32> [#uses=1]
1619 Instcombine prefers to strength reduce relational comparisons to equality
1620 comparisons when possible, this should be another case of that. This could
1621 be handled pretty easily in InstCombiner::visitICmpInstWithInstAndIntCst, but it
1622 looks like InstCombiner::visitICmpInstWithInstAndIntCst should really already
1623 be redesigned to use ComputeMaskedBits and friends.
1626 //===---------------------------------------------------------------------===//
1628 int x(int a) { return (a&0xf0)>>4; }
1637 movzbl 4(%esp), %eax
1641 //===---------------------------------------------------------------------===//
1643 Re-implement atomic builtins __sync_add_and_fetch() and __sync_sub_and_fetch
1646 When the return value is not used (i.e. only care about the value in the
1647 memory), x86 does not have to use add to implement these. Instead, it can use
1648 add, sub, inc, dec instructions with the "lock" prefix.
1650 This is currently implemented using a bit of instruction selection trick. The
1651 issue is the target independent pattern produces one output and a chain and we
1652 want to map it into one that just output a chain. The current trick is to select
1653 it into a MERGE_VALUES with the first definition being an implicit_def. The
1654 proper solution is to add new ISD opcodes for the no-output variant. DAG
1655 combiner can then transform the node before it gets to target node selection.
1657 Problem #2 is we are adding a whole bunch of x86 atomic instructions when in
1658 fact these instructions are identical to the non-lock versions. We need a way to
1659 add target specific information to target nodes and have this information
1660 carried over to machine instructions. Asm printer (or JIT) can use this
1661 information to add the "lock" prefix.
1663 //===---------------------------------------------------------------------===//
1665 _Bool bar(int *x) { return *x & 1; }
1667 define zeroext i1 @bar(i32* nocapture %x) nounwind readonly {
1669 %tmp1 = load i32* %x ; <i32> [#uses=1]
1670 %and = and i32 %tmp1, 1 ; <i32> [#uses=1]
1671 %tobool = icmp ne i32 %and, 0 ; <i1> [#uses=1]
1683 Missed optimization: should be movl+andl.
1685 //===---------------------------------------------------------------------===//
1687 Consider the following two functions compiled with clang:
1688 _Bool foo(int *x) { return !(*x & 4); }
1689 unsigned bar(int *x) { return !(*x & 4); }
1706 The second function generates more code even though the two functions are
1707 are functionally identical.
1709 //===---------------------------------------------------------------------===//
1711 Take the following C code:
1712 int x(int y) { return (y & 63) << 14; }
1714 Code produced by gcc:
1720 Code produced by clang:
1726 The code produced by gcc is 3 bytes shorter. This sort of construct often
1727 shows up with bitfields.
1729 //===---------------------------------------------------------------------===//
1731 Take the following C code:
1732 int f(int a, int b) { return (unsigned char)a == (unsigned char)b; }
1734 We generate the following IR with clang:
1735 define i32 @f(i32 %a, i32 %b) nounwind readnone {
1737 %tmp = xor i32 %b, %a ; <i32> [#uses=1]
1738 %tmp6 = and i32 %tmp, 255 ; <i32> [#uses=1]
1739 %cmp = icmp eq i32 %tmp6, 0 ; <i1> [#uses=1]
1740 %conv5 = zext i1 %cmp to i32 ; <i32> [#uses=1]
1744 And the following x86 code:
1751 A cmpb instead of the xorl+testb would be one instruction shorter.
1753 //===---------------------------------------------------------------------===//
1755 Given the following C code:
1756 int f(int a, int b) { return (signed char)a == (signed char)b; }
1758 We generate the following IR with clang:
1759 define i32 @f(i32 %a, i32 %b) nounwind readnone {
1761 %sext = shl i32 %a, 24 ; <i32> [#uses=1]
1762 %conv1 = ashr i32 %sext, 24 ; <i32> [#uses=1]
1763 %sext6 = shl i32 %b, 24 ; <i32> [#uses=1]
1764 %conv4 = ashr i32 %sext6, 24 ; <i32> [#uses=1]
1765 %cmp = icmp eq i32 %conv1, %conv4 ; <i1> [#uses=1]
1766 %conv5 = zext i1 %cmp to i32 ; <i32> [#uses=1]
1770 And the following x86 code:
1779 It should be possible to eliminate the sign extensions.
1781 //===---------------------------------------------------------------------===//
1783 LLVM misses a load+store narrowing opportunity in this code:
1785 %struct.bf = type { i64, i16, i16, i32 }
1787 @bfi = external global %struct.bf* ; <%struct.bf**> [#uses=2]
1789 define void @t1() nounwind ssp {
1791 %0 = load %struct.bf** @bfi, align 8 ; <%struct.bf*> [#uses=1]
1792 %1 = getelementptr %struct.bf* %0, i64 0, i32 1 ; <i16*> [#uses=1]
1793 %2 = bitcast i16* %1 to i32* ; <i32*> [#uses=2]
1794 %3 = load i32* %2, align 1 ; <i32> [#uses=1]
1795 %4 = and i32 %3, -65537 ; <i32> [#uses=1]
1796 store i32 %4, i32* %2, align 1
1797 %5 = load %struct.bf** @bfi, align 8 ; <%struct.bf*> [#uses=1]
1798 %6 = getelementptr %struct.bf* %5, i64 0, i32 1 ; <i16*> [#uses=1]
1799 %7 = bitcast i16* %6 to i32* ; <i32*> [#uses=2]
1800 %8 = load i32* %7, align 1 ; <i32> [#uses=1]
1801 %9 = and i32 %8, -131073 ; <i32> [#uses=1]
1802 store i32 %9, i32* %7, align 1
1806 LLVM currently emits this:
1808 movq bfi(%rip), %rax
1809 andl $-65537, 8(%rax)
1810 movq bfi(%rip), %rax
1811 andl $-131073, 8(%rax)
1814 It could narrow the loads and stores to emit this:
1816 movq bfi(%rip), %rax
1818 movq bfi(%rip), %rax
1822 The trouble is that there is a TokenFactor between the store and the
1823 load, making it non-trivial to determine if there's anything between
1824 the load and the store which would prohibit narrowing.
1826 //===---------------------------------------------------------------------===//
1829 void foo(unsigned x) {
1831 else if (x == 1) qux();
1834 currently compiles into:
1842 the testl could be removed:
1849 0 is the only unsigned number < 1.
1851 //===---------------------------------------------------------------------===//
1855 %0 = type { i32, i1 }
1857 define i32 @add32carry(i32 %sum, i32 %x) nounwind readnone ssp {
1859 %uadd = tail call %0 @llvm.uadd.with.overflow.i32(i32 %sum, i32 %x)
1860 %cmp = extractvalue %0 %uadd, 1
1861 %inc = zext i1 %cmp to i32
1862 %add = add i32 %x, %sum
1863 %z.0 = add i32 %add, %inc
1867 declare %0 @llvm.uadd.with.overflow.i32(i32, i32) nounwind readnone
1871 _add32carry: ## @add32carry
1881 leal (%rsi,%rdi), %eax
1886 //===---------------------------------------------------------------------===//