1 //===- README.txt - Notes for improving PowerPC-specific code gen ---------===//
4 * lmw/stmw pass a la arm load store optimizer for prolog/epilog
6 ===-------------------------------------------------------------------------===
10 long f2 (long x) { return 0xfffffff000000000UL; }
11 long f3 (long x) { return 0x1ffffffffUL; }
38 ===-------------------------------------------------------------------------===
42 unsigned add32carry(unsigned sum, unsigned x) {
49 Should compile to something like:
59 rlwinm r4, r4, 29, 31, 31
64 ===-------------------------------------------------------------------------===
66 Support 'update' load/store instructions. These are cracked on the G5, but are
69 With preinc enabled, this:
71 long *%test4(long *%X, long *%dest) {
72 %Y = getelementptr long* %X, int 4
74 store long %A, long* %dest
89 with -sched=list-burr, I get:
98 ===-------------------------------------------------------------------------===
100 We compile the hottest inner loop of viterbi to:
111 bne cr0, LBB1_83 ;bb420.i
113 The CBE manages to produce:
124 This could be much better (bdnz instead of bdz) but it still beats us. If we
125 produced this with bdnz, the loop would be a single dispatch group.
127 ===-------------------------------------------------------------------------===
144 This is effectively a simple form of predication.
146 ===-------------------------------------------------------------------------===
148 Lump the constant pool for each function into ONE pic object, and reference
149 pieces of it as offsets from the start. For functions like this (contrived
150 to have lots of constants obviously):
152 double X(double Y) { return (Y*1.23 + 4.512)*2.34 + 14.38; }
157 lis r2, ha16(.CPI_X_0)
158 lfd f0, lo16(.CPI_X_0)(r2)
159 lis r2, ha16(.CPI_X_1)
160 lfd f2, lo16(.CPI_X_1)(r2)
162 lis r2, ha16(.CPI_X_2)
163 lfd f1, lo16(.CPI_X_2)(r2)
164 lis r2, ha16(.CPI_X_3)
165 lfd f2, lo16(.CPI_X_3)(r2)
169 It would be better to materialize .CPI_X into a register, then use immediates
170 off of the register to avoid the lis's. This is even more important in PIC
173 Note that this (and the static variable version) is discussed here for GCC:
174 http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00133.html
176 Here's another example (the sgn function):
177 double testf(double a) {
178 return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
181 it produces a BB like this:
183 lis r2, ha16(LCPI1_0)
184 lfs f0, lo16(LCPI1_0)(r2)
185 lis r2, ha16(LCPI1_1)
186 lis r3, ha16(LCPI1_2)
187 lfs f2, lo16(LCPI1_2)(r3)
188 lfs f3, lo16(LCPI1_1)(r2)
193 ===-------------------------------------------------------------------------===
195 PIC Code Gen IPO optimization:
197 Squish small scalar globals together into a single global struct, allowing the
198 address of the struct to be CSE'd, avoiding PIC accesses (also reduces the size
199 of the GOT on targets with one).
201 Note that this is discussed here for GCC:
202 http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00133.html
204 ===-------------------------------------------------------------------------===
206 Compile offsets from allocas:
209 %X = alloca { int, int }
210 %Y = getelementptr {int,int}* %X, int 0, uint 1
214 into a single add, not two:
221 --> important for C++.
223 ===-------------------------------------------------------------------------===
225 No loads or stores of the constants should be needed:
227 struct foo { double X, Y; };
228 void xxx(struct foo F);
229 void bar() { struct foo R = { 1.0, 2.0 }; xxx(R); }
231 ===-------------------------------------------------------------------------===
235 We still generate calls to foo$stub, and stubs, on Darwin. This is not
236 necessary when building with the Leopard (10.5) or later linker, as stubs are
237 generated by ld when necessary. Parameterizing this based on the deployment
238 target (-mmacosx-version-min) is probably enough. x86-32 does this right, see
241 ===-------------------------------------------------------------------------===
243 Darwin Stub LICM optimization:
249 Have to go through an indirect stub if bar is external or linkonce. It would
250 be better to compile it as:
255 which only computes the address of bar once (instead of each time through the
256 stub). This is Darwin specific and would have to be done in the code generator.
257 Probably not a win on x86.
259 ===-------------------------------------------------------------------------===
261 Simple IPO for argument passing, change:
262 void foo(int X, double Y, int Z) -> void foo(int X, int Z, double Y)
264 the Darwin ABI specifies that any integer arguments in the first 32 bytes worth
265 of arguments get assigned to r3 through r10. That is, if you have a function
266 foo(int, double, int) you get r3, f1, r6, since the 64 bit double ate up the
267 argument bytes for r4 and r5. The trick then would be to shuffle the argument
268 order for functions we can internalize so that the maximum number of
269 integers/pointers get passed in regs before you see any of the fp arguments.
271 Instead of implementing this, it would actually probably be easier to just
272 implement a PPC fastcc, where we could do whatever we wanted to the CC,
273 including having this work sanely.
275 ===-------------------------------------------------------------------------===
277 Fix Darwin FP-In-Integer Registers ABI
279 Darwin passes doubles in structures in integer registers, which is very very
280 bad. Add something like a BITCAST to LLVM, then do an i-p transformation that
281 percolates these things out of functions.
283 Check out how horrible this is:
284 http://gcc.gnu.org/ml/gcc/2005-10/msg01036.html
286 This is an extension of "interprocedural CC unmunging" that can't be done with
289 ===-------------------------------------------------------------------------===
296 return b * 3; // ignore the fact that this is always 3.
302 into something not this:
307 rlwinm r2, r2, 29, 31, 31
309 bgt cr0, LBB1_2 ; UnifiedReturnBlock
311 rlwinm r2, r2, 0, 31, 31
314 LBB1_2: ; UnifiedReturnBlock
318 In particular, the two compares (marked 1) could be shared by reversing one.
319 This could be done in the dag combiner, by swapping a BR_CC when a SETCC of the
320 same operands (but backwards) exists. In this case, this wouldn't save us
321 anything though, because the compares still wouldn't be shared.
323 ===-------------------------------------------------------------------------===
325 We should custom expand setcc instead of pretending that we have it. That
326 would allow us to expose the access of the crbit after the mfcr, allowing
327 that access to be trivially folded into other ops. A simple example:
329 int foo(int a, int b) { return (a < b) << 4; }
336 rlwinm r2, r2, 29, 31, 31
340 ===-------------------------------------------------------------------------===
342 Fold add and sub with constant into non-extern, non-weak addresses so this:
345 void bar(int b) { a = b; }
346 void foo(unsigned char *c) {
363 lbz r2, lo16(_a+3)(r2)
367 ===-------------------------------------------------------------------------===
369 We generate really bad code for this:
371 int f(signed char *a, _Bool b, _Bool c) {
377 ===-------------------------------------------------------------------------===
380 int test(unsigned *P) { return *P >> 24; }
395 ===-------------------------------------------------------------------------===
397 On the G5, logical CR operations are more expensive in their three
398 address form: ops that read/write the same register are half as expensive as
399 those that read from two registers that are different from their destination.
401 We should model this with two separate instructions. The isel should generate
402 the "two address" form of the instructions. When the register allocator
403 detects that it needs to insert a copy due to the two-addresness of the CR
404 logical op, it will invoke PPCInstrInfo::convertToThreeAddress. At this point
405 we can convert to the "three address" instruction, to save code space.
407 This only matters when we start generating cr logical ops.
409 ===-------------------------------------------------------------------------===
411 We should compile these two functions to the same thing:
414 void f(int a, int b, int *P) {
415 *P = (a-b)>=0?(a-b):(b-a);
417 void g(int a, int b, int *P) {
421 Further, they should compile to something better than:
427 bgt cr0, LBB2_2 ; entry
444 ... which is much nicer.
446 This theoretically may help improve twolf slightly (used in dimbox.c:142?).
448 ===-------------------------------------------------------------------------===
451 define i32 @clamp0g(i32 %a) {
453 %cmp = icmp slt i32 %a, 0
454 %sel = select i1 %cmp, i32 0, i32 %a
458 Is compile to this with the PowerPC (32-bit) backend:
470 This could be reduced to the much simpler:
477 ===-------------------------------------------------------------------------===
479 int foo(int N, int ***W, int **TK, int X) {
482 for (t = 0; t < N; ++t)
483 for (i = 0; i < 4; ++i)
484 W[t / X][i][t % X] = TK[i][t];
489 We generate relatively atrocious code for this loop compared to gcc.
491 We could also strength reduce the rem and the div:
492 http://www.lcs.mit.edu/pubs/pdf/MIT-LCS-TM-600.pdf
494 ===-------------------------------------------------------------------------===
496 float foo(float X) { return (int)(X); }
511 We could use a target dag combine to turn the lwz/extsw into an lwa when the
512 lwz has a single use. Since LWA is cracked anyway, this would be a codesize
515 ===-------------------------------------------------------------------------===
517 We generate ugly code for this:
519 void func(unsigned int *ret, float dx, float dy, float dz, float dw) {
521 if(dx < -dw) code |= 1;
522 if(dx > dw) code |= 2;
523 if(dy < -dw) code |= 4;
524 if(dy > dw) code |= 8;
525 if(dz < -dw) code |= 16;
526 if(dz > dw) code |= 32;
530 ===-------------------------------------------------------------------------===
532 %struct.B = type { i8, [3 x i8] }
534 define void @bar(%struct.B* %b) {
536 %tmp = bitcast %struct.B* %b to i32* ; <uint*> [#uses=1]
537 %tmp = load i32* %tmp ; <uint> [#uses=1]
538 %tmp3 = bitcast %struct.B* %b to i32* ; <uint*> [#uses=1]
539 %tmp4 = load i32* %tmp3 ; <uint> [#uses=1]
540 %tmp8 = bitcast %struct.B* %b to i32* ; <uint*> [#uses=2]
541 %tmp9 = load i32* %tmp8 ; <uint> [#uses=1]
542 %tmp4.mask17 = shl i32 %tmp4, i8 1 ; <uint> [#uses=1]
543 %tmp1415 = and i32 %tmp4.mask17, 2147483648 ; <uint> [#uses=1]
544 %tmp.masked = and i32 %tmp, 2147483648 ; <uint> [#uses=1]
545 %tmp11 = or i32 %tmp1415, %tmp.masked ; <uint> [#uses=1]
546 %tmp12 = and i32 %tmp9, 2147483647 ; <uint> [#uses=1]
547 %tmp13 = or i32 %tmp12, %tmp11 ; <uint> [#uses=1]
548 store i32 %tmp13, i32* %tmp8
558 rlwimi r2, r4, 0, 0, 0
562 We could collapse a bunch of those ORs and ANDs and generate the following
567 rlwinm r4, r2, 1, 0, 0
572 ===-------------------------------------------------------------------------===
576 unsigned test6(unsigned x) {
577 return ((x & 0x00FF0000) >> 16) | ((x & 0x000000FF) << 16);
584 rlwinm r3, r3, 16, 0, 31
593 rlwinm r3,r3,16,24,31
598 ===-------------------------------------------------------------------------===
600 Consider a function like this:
602 float foo(float X) { return X + 1234.4123f; }
604 The FP constant ends up in the constant pool, so we need to get the LR register.
605 This ends up producing code like this:
614 addis r2, r2, ha16(.CPI_foo_0-"L00000$pb")
615 lfs f0, lo16(.CPI_foo_0-"L00000$pb")(r2)
621 This is functional, but there is no reason to spill the LR register all the way
622 to the stack (the two marked instrs): spilling it to a GPR is quite enough.
624 Implementing this will require some codegen improvements. Nate writes:
626 "So basically what we need to support the "no stack frame save and restore" is a
627 generalization of the LR optimization to "callee-save regs".
629 Currently, we have LR marked as a callee-save reg. The register allocator sees
630 that it's callee save, and spills it directly to the stack.
632 Ideally, something like this would happen:
634 LR would be in a separate register class from the GPRs. The class of LR would be
635 marked "unspillable". When the register allocator came across an unspillable
636 reg, it would ask "what is the best class to copy this into that I *can* spill"
637 If it gets a class back, which it will in this case (the gprs), it grabs a free
638 register of that class. If it is then later necessary to spill that reg, so be
641 ===-------------------------------------------------------------------------===
645 return X ? 524288 : 0;
653 beq cr0, LBB1_2 ;entry
666 This sort of thing occurs a lot due to globalopt.
668 ===-------------------------------------------------------------------------===
672 define i32 @bar(i32 %x) nounwind readnone ssp {
674 %0 = icmp eq i32 %x, 0 ; <i1> [#uses=1]
675 %neg = sext i1 %0 to i32 ; <i32> [#uses=1]
687 it would be better to produce:
694 ===-------------------------------------------------------------------------===
696 We currently compile 32-bit bswap:
698 declare i32 @llvm.bswap.i32(i32 %A)
699 define i32 @test(i32 %A) {
700 %B = call i32 @llvm.bswap.i32(i32 %A)
707 rlwinm r2, r3, 24, 16, 23
709 rlwimi r2, r3, 8, 24, 31
710 rlwimi r4, r3, 8, 8, 15
711 rlwimi r4, r2, 0, 16, 31
715 it would be more efficient to produce:
718 rlwinm r3,r3,8,0xffffffff
720 rlwimi r3,r0,24,16,23
723 ===-------------------------------------------------------------------------===
725 test/CodeGen/PowerPC/2007-03-24-cntlzd.ll compiles to:
727 __ZNK4llvm5APInt17countLeadingZerosEv:
730 or r2, r2, r2 <<-- silly.
734 The dead or is a 'truncate' from 64- to 32-bits.
736 ===-------------------------------------------------------------------------===
738 We generate horrible ppc code for this:
750 addi r5, r5, 1 ;; Extra IV for the exit value compare.
754 xoris r6, r5, 30 ;; This is due to a large immediate.
755 cmplwi cr0, r6, 33920
758 //===---------------------------------------------------------------------===//
762 inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
763 { return std::make_pair(a + b, a + b < a); }
764 bool no_overflow(unsigned a, unsigned b)
765 { return !full_add(a, b).second; }
782 rlwinm r2, r2, 29, 31, 31
786 //===---------------------------------------------------------------------===//
788 We compile some FP comparisons into an mfcr with two rlwinms and an or. For
791 int test(double x, double y) { return islessequal(x, y);}
792 int test2(double x, double y) { return islessgreater(x, y);}
793 int test3(double x, double y) { return !islessequal(x, y);}
795 Compiles into (all three are similar, but the bits differ):
800 rlwinm r3, r2, 29, 31, 31
801 rlwinm r2, r2, 31, 31, 31
805 GCC compiles this into:
814 which is more efficient and can use mfocr. See PR642 for some more context.
816 //===---------------------------------------------------------------------===//
818 void foo(float *data, float d) {
820 for (i = 0; i < 8000; i++)
823 void foo2(float *data, float d) {
826 for (i = 0; i < 8000; i++) {
839 cmplwi cr0, r4, 32000
848 cmplwi cr0, r4, 32000
853 The 'mr' could be eliminated to folding the add into the cmp better.
855 //===---------------------------------------------------------------------===//
856 Codegen for the following (low-probability) case deteriorated considerably
857 when the correctness fixes for unordered comparisons went in (PR 642, 58871).
858 It should be possible to recover the code quality described in the comments.
860 ; RUN: llvm-as < %s | llc -march=ppc32 | grep or | count 3
861 ; This should produce one 'or' or 'cror' instruction per function.
863 ; RUN: llvm-as < %s | llc -march=ppc32 | grep mfcr | count 3
866 define i32 @test(double %x, double %y) nounwind {
868 %tmp3 = fcmp ole double %x, %y ; <i1> [#uses=1]
869 %tmp345 = zext i1 %tmp3 to i32 ; <i32> [#uses=1]
873 define i32 @test2(double %x, double %y) nounwind {
875 %tmp3 = fcmp one double %x, %y ; <i1> [#uses=1]
876 %tmp345 = zext i1 %tmp3 to i32 ; <i32> [#uses=1]
880 define i32 @test3(double %x, double %y) nounwind {
882 %tmp3 = fcmp ugt double %x, %y ; <i1> [#uses=1]
883 %tmp34 = zext i1 %tmp3 to i32 ; <i32> [#uses=1]
886 //===----------------------------------------------------------------------===//
887 ; RUN: llvm-as < %s | llc -march=ppc32 | not grep fneg
889 ; This could generate FSEL with appropriate flags (FSEL is not IEEE-safe, and
890 ; should not be generated except with -enable-finite-only-fp-math or the like).
891 ; With the correctness fixes for PR642 (58871) LowerSELECT_CC would need to
892 ; recognize a more elaborate tree than a simple SETxx.
894 define double @test_FNEG_sel(double %A, double %B, double %C) {
895 %D = fsub double -0.000000e+00, %A ; <double> [#uses=1]
896 %Cond = fcmp ugt double %D, -0.000000e+00 ; <i1> [#uses=1]
897 %E = select i1 %Cond, double %B, double %C ; <double> [#uses=1]
901 //===----------------------------------------------------------------------===//
902 The save/restore sequence for CR in prolog/epilog is terrible:
903 - Each CR subreg is saved individually, rather than doing one save as a unit.
904 - On Darwin, the save is done after the decrement of SP, which means the offset
905 from SP of the save slot can be too big for a store instruction, which means we
906 need an additional register (currently hacked in 96015+96020; the solution there
907 is correct, but poor).
908 - On SVR4 the same thing can happen, and I don't think saving before the SP
909 decrement is safe on that target, as there is no red zone. This is currently
910 broken AFAIK, although it's not a target I can exercise.
911 The following demonstrates the problem:
912 extern void bar(char *p);
916 __asm__("" ::: "cr2");