lib/Target/PowerPC/README.txt

   1 //===- README.txt - Notes for improving PowerPC-specific code gen ---------===//
   2
   3 TODO:
   4 * lmw/stmw pass a la arm load store optimizer for prolog/epilog
   5
   6 ===-------------------------------------------------------------------------===
   7
   8 On PPC64, this:
   9
  10 long f2 (long x) { return 0xfffffff000000000UL; }
  11 long f3 (long x) { return 0x1ffffffffUL; }
  12
  13 could compile into:
  14
  15 _f2:
  16         li r3,-1
  17         rldicr r3,r3,0,27
  18         blr
  19 _f3:
  20         li r3,-1
  21         rldicl r3,r3,0,31
  22         blr
  23
  24 we produce:
  25
  26 _f2:
  27         lis r2, 4095
  28         ori r2, r2, 65535
  29         sldi r3, r2, 36
  30         blr
  31 _f3:
  32         li r2, 1
  33         sldi r2, r2, 32
  34         oris r2, r2, 65535
  35         ori r3, r2, 65535
  36         blr
  37
  38 ===-------------------------------------------------------------------------===
  39
  40 This code:
  41
  42 unsigned add32carry(unsigned sum, unsigned x) {
  43  unsigned z = sum + x;
  44  if (sum + x < x)
  45      z++;
  46  return z;
  47 }
  48
  49 Should compile to something like:
  50
  51         addc r3,r3,r4
  52         addze r3,r3
  53
  54 instead we get:
  55
  56         add r3, r4, r3
  57         cmplw cr7, r3, r4
  58         mfcr r4 ; 1
  59         rlwinm r4, r4, 29, 31, 31
  60         add r3, r3, r4
  61
  62 Ick.
  63
  64 ===-------------------------------------------------------------------------===
  65
  66 Support 'update' load/store instructions.  These are cracked on the G5, but are
  67 still a codesize win.
  68
  69 With preinc enabled, this:
  70
  71 long *%test4(long *%X, long *%dest) {
  72         %Y = getelementptr long* %X, int 4
  73         %A = load long* %Y
  74         store long %A, long* %dest
  75         ret long* %Y
  76 }
  77
  78 compiles to:
  79
  80 _test4:
  81         mr r2, r3
  82         lwzu r5, 32(r2)
  83         lwz r3, 36(r3)
  84         stw r5, 0(r4)
  85         stw r3, 4(r4)
  86         mr r3, r2
  87         blr
  88
  89 with -sched=list-burr, I get:
  90
  91 _test4:
  92         lwz r2, 36(r3)
  93         lwzu r5, 32(r3)
  94         stw r2, 4(r4)
  95         stw r5, 0(r4)
  96         blr
  97
  98 ===-------------------------------------------------------------------------===
  99
 100 We compile the hottest inner loop of viterbi to:
 101
 102         li r6, 0
 103         b LBB1_84       ;bb432.i
 104 LBB1_83:        ;bb420.i
 105         lbzx r8, r5, r7
 106         addi r6, r7, 1
 107         stbx r8, r4, r7
 108 LBB1_84:        ;bb432.i
 109         mr r7, r6
 110         cmplwi cr0, r7, 143
 111         bne cr0, LBB1_83        ;bb420.i
 112
 113 The CBE manages to produce:
 114
 115         li r0, 143
 116         mtctr r0
 117 loop:
 118         lbzx r2, r2, r11
 119         stbx r0, r2, r9
 120         addi r2, r2, 1
 121         bdz later
 122         b loop
 123
 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.
 126
 127 ===-------------------------------------------------------------------------===
 128
 129 Lump the constant pool for each function into ONE pic object, and reference
 130 pieces of it as offsets from the start.  For functions like this (contrived
 131 to have lots of constants obviously):
 132
 133 double X(double Y) { return (Y*1.23 + 4.512)*2.34 + 14.38; }
 134
 135 We generate:
 136
 137 _X:
 138         lis r2, ha16(.CPI_X_0)
 139         lfd f0, lo16(.CPI_X_0)(r2)
 140         lis r2, ha16(.CPI_X_1)
 141         lfd f2, lo16(.CPI_X_1)(r2)
 142         fmadd f0, f1, f0, f2
 143         lis r2, ha16(.CPI_X_2)
 144         lfd f1, lo16(.CPI_X_2)(r2)
 145         lis r2, ha16(.CPI_X_3)
 146         lfd f2, lo16(.CPI_X_3)(r2)
 147         fmadd f1, f0, f1, f2
 148         blr
 149
 150 It would be better to materialize .CPI_X into a register, then use immediates
 151 off of the register to avoid the lis's.  This is even more important in PIC
 152 mode.
 153
 154 Note that this (and the static variable version) is discussed here for GCC:
 155 http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00133.html
 156
 157 Here's another example (the sgn function):
 158 double testf(double a) {
 159        return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
 160 }
 161
 162 it produces a BB like this:
 163 LBB1_1: ; cond_true
 164         lis r2, ha16(LCPI1_0)
 165         lfs f0, lo16(LCPI1_0)(r2)
 166         lis r2, ha16(LCPI1_1)
 167         lis r3, ha16(LCPI1_2)
 168         lfs f2, lo16(LCPI1_2)(r3)
 169         lfs f3, lo16(LCPI1_1)(r2)
 170         fsub f0, f0, f1
 171         fsel f1, f0, f2, f3
 172         blr
 173
 174 ===-------------------------------------------------------------------------===
 175
 176 PIC Code Gen IPO optimization:
 177
 178 Squish small scalar globals together into a single global struct, allowing the
 179 address of the struct to be CSE'd, avoiding PIC accesses (also reduces the size
 180 of the GOT on targets with one).
 181
 182 Note that this is discussed here for GCC:
 183 http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00133.html
 184
 185 ===-------------------------------------------------------------------------===
 186
 187 No loads or stores of the constants should be needed:
 188
 189 struct foo { double X, Y; };
 190 void xxx(struct foo F);
 191 void bar() { struct foo R = { 1.0, 2.0 }; xxx(R); }
 192
 193 ===-------------------------------------------------------------------------===
 194
 195 Darwin Stub removal:
 196
 197 We still generate calls to foo$stub, and stubs, on Darwin.  This is not
 198 necessary when building with the Leopard (10.5) or later linker, as stubs are
 199 generated by ld when necessary.  Parameterizing this based on the deployment
 200 target (-mmacosx-version-min) is probably enough.  x86-32 does this right, see
 201 its logic.
 202
 203 ===-------------------------------------------------------------------------===
 204
 205 Darwin Stub LICM optimization:
 206
 207 Loops like this:
 208
 209   for (...)  bar();
 210
 211 Have to go through an indirect stub if bar is external or linkonce.  It would
 212 be better to compile it as:
 213
 214      fp = &bar;
 215      for (...)  fp();
 216
 217 which only computes the address of bar once (instead of each time through the
 218 stub).  This is Darwin specific and would have to be done in the code generator.
 219 Probably not a win on x86.
 220
 221 ===-------------------------------------------------------------------------===
 222
 223 Simple IPO for argument passing, change:
 224   void foo(int X, double Y, int Z) -> void foo(int X, int Z, double Y)
 225
 226 the Darwin ABI specifies that any integer arguments in the first 32 bytes worth
 227 of arguments get assigned to r3 through r10. That is, if you have a function
 228 foo(int, double, int) you get r3, f1, r6, since the 64 bit double ate up the
 229 argument bytes for r4 and r5. The trick then would be to shuffle the argument
 230 order for functions we can internalize so that the maximum number of
 231 integers/pointers get passed in regs before you see any of the fp arguments.
 232
 233 Instead of implementing this, it would actually probably be easier to just
 234 implement a PPC fastcc, where we could do whatever we wanted to the CC,
 235 including having this work sanely.
 236
 237 ===-------------------------------------------------------------------------===
 238
 239 Fix Darwin FP-In-Integer Registers ABI
 240
 241 Darwin passes doubles in structures in integer registers, which is very very
 242 bad.  Add something like a BITCAST to LLVM, then do an i-p transformation that
 243 percolates these things out of functions.
 244
 245 Check out how horrible this is:
 246 http://gcc.gnu.org/ml/gcc/2005-10/msg01036.html
 247
 248 This is an extension of "interprocedural CC unmunging" that can't be done with
 249 just fastcc.
 250
 251 ===-------------------------------------------------------------------------===
 252
 253 Compile this:
 254
 255 int foo(int a) {
 256   int b = (a < 8);
 257   if (b) {
 258     return b * 3;     // ignore the fact that this is always 3.
 259   } else {
 260     return 2;
 261   }
 262 }
 263
 264 into something not this:
 265
 266 _foo:
 267 1)      cmpwi cr7, r3, 8
 268         mfcr r2, 1
 269         rlwinm r2, r2, 29, 31, 31
 270 1)      cmpwi cr0, r3, 7
 271         bgt cr0, LBB1_2 ; UnifiedReturnBlock
 272 LBB1_1: ; then
 273         rlwinm r2, r2, 0, 31, 31
 274         mulli r3, r2, 3
 275         blr
 276 LBB1_2: ; UnifiedReturnBlock
 277         li r3, 2
 278         blr
 279
 280 In particular, the two compares (marked 1) could be shared by reversing one.
 281 This could be done in the dag combiner, by swapping a BR_CC when a SETCC of the
 282 same operands (but backwards) exists.  In this case, this wouldn't save us
 283 anything though, because the compares still wouldn't be shared.
 284
 285 ===-------------------------------------------------------------------------===
 286
 287 We should custom expand setcc instead of pretending that we have it.  That
 288 would allow us to expose the access of the crbit after the mfcr, allowing
 289 that access to be trivially folded into other ops.  A simple example:
 290
 291 int foo(int a, int b) { return (a < b) << 4; }
 292
 293 compiles into:
 294
 295 _foo:
 296         cmpw cr7, r3, r4
 297         mfcr r2, 1
 298         rlwinm r2, r2, 29, 31, 31
 299         slwi r3, r2, 4
 300         blr
 301
 302 ===-------------------------------------------------------------------------===
 303
 304 Fold add and sub with constant into non-extern, non-weak addresses so this:
 305
 306 static int a;
 307 void bar(int b) { a = b; }
 308 void foo(unsigned char *c) {
 309   *c = a;
 310 }
 311
 312 So that
 313
 314 _foo:
 315         lis r2, ha16(_a)
 316         la r2, lo16(_a)(r2)
 317         lbz r2, 3(r2)
 318         stb r2, 0(r3)
 319         blr
 320
 321 Becomes
 322
 323 _foo:
 324         lis r2, ha16(_a+3)
 325         lbz r2, lo16(_a+3)(r2)
 326         stb r2, 0(r3)
 327         blr
 328
 329 ===-------------------------------------------------------------------------===
 330
 331 We generate really bad code for this:
 332
 333 int f(signed char *a, _Bool b, _Bool c) {
 334    signed char t = 0;
 335   if (b)  t = *a;
 336   if (c)  *a = t;
 337 }
 338
 339 ===-------------------------------------------------------------------------===
 340
 341 This:
 342 int test(unsigned *P) { return *P >> 24; }
 343
 344 Should compile to:
 345
 346 _test:
 347         lbz r3,0(r3)
 348         blr
 349
 350 not:
 351
 352 _test:
 353         lwz r2, 0(r3)
 354         srwi r3, r2, 24
 355         blr
 356
 357 ===-------------------------------------------------------------------------===
 358
 359 On the G5, logical CR operations are more expensive in their three
 360 address form: ops that read/write the same register are half as expensive as
 361 those that read from two registers that are different from their destination.
 362
 363 We should model this with two separate instructions.  The isel should generate
 364 the "two address" form of the instructions.  When the register allocator
 365 detects that it needs to insert a copy due to the two-addresness of the CR
 366 logical op, it will invoke PPCInstrInfo::convertToThreeAddress.  At this point
 367 we can convert to the "three address" instruction, to save code space.
 368
 369 This only matters when we start generating cr logical ops.
 370
 371 ===-------------------------------------------------------------------------===
 372
 373 We should compile these two functions to the same thing:
 374
 375 #include <stdlib.h>
 376 void f(int a, int b, int *P) {
 377   *P = (a-b)>=0?(a-b):(b-a);
 378 }
 379 void g(int a, int b, int *P) {
 380   *P = abs(a-b);
 381 }
 382
 383 Further, they should compile to something better than:
 384
 385 _g:
 386         subf r2, r4, r3
 387         subfic r3, r2, 0
 388         cmpwi cr0, r2, -1
 389         bgt cr0, LBB2_2 ; entry
 390 LBB2_1: ; entry
 391         mr r2, r3
 392 LBB2_2: ; entry
 393         stw r2, 0(r5)
 394         blr
 395
 396 GCC produces:
 397
 398 _g:
 399         subf r4,r4,r3
 400         srawi r2,r4,31
 401         xor r0,r2,r4
 402         subf r0,r2,r0
 403         stw r0,0(r5)
 404         blr
 405
 406 ... which is much nicer.
 407
 408 This theoretically may help improve twolf slightly (used in dimbox.c:142?).
 409
 410 ===-------------------------------------------------------------------------===
 411
 412 PR5945: This:
 413 define i32 @clamp0g(i32 %a) {
 414 entry:
 415         %cmp = icmp slt i32 %a, 0
 416         %sel = select i1 %cmp, i32 0, i32 %a
 417         ret i32 %sel
 418 }
 419
 420 Is compile to this with the PowerPC (32-bit) backend:
 421
 422 _clamp0g:
 423         cmpwi cr0, r3, 0
 424         li r2, 0
 425         blt cr0, LBB1_2
 426 ; BB#1:                                                     ; %entry
 427         mr r2, r3
 428 LBB1_2:                                                     ; %entry
 429         mr r3, r2
 430         blr
 431
 432 This could be reduced to the much simpler:
 433
 434 _clamp0g:
 435         srawi r2, r3, 31
 436         andc r3, r3, r2
 437         blr
 438
 439 ===-------------------------------------------------------------------------===
 440
 441 int foo(int N, int ***W, int **TK, int X) {
 442   int t, i;
 443
 444   for (t = 0; t < N; ++t)
 445     for (i = 0; i < 4; ++i)
 446       W[t / X][i][t % X] = TK[i][t];
 447
 448   return 5;
 449 }
 450
 451 We generate relatively atrocious code for this loop compared to gcc.
 452
 453 We could also strength reduce the rem and the div:
 454 http://www.lcs.mit.edu/pubs/pdf/MIT-LCS-TM-600.pdf
 455
 456 ===-------------------------------------------------------------------------===
 457
 458 float foo(float X) { return (int)(X); }
 459
 460 Currently produces:
 461
 462 _foo:
 463         fctiwz f0, f1
 464         stfd f0, -8(r1)
 465         lwz r2, -4(r1)
 466         extsw r2, r2
 467         std r2, -16(r1)
 468         lfd f0, -16(r1)
 469         fcfid f0, f0
 470         frsp f1, f0
 471         blr
 472
 473 We could use a target dag combine to turn the lwz/extsw into an lwa when the
 474 lwz has a single use.  Since LWA is cracked anyway, this would be a codesize
 475 win only.
 476
 477 ===-------------------------------------------------------------------------===
 478
 479 We generate ugly code for this:
 480
 481 void func(unsigned int *ret, float dx, float dy, float dz, float dw) {
 482   unsigned code = 0;
 483   if(dx < -dw) code |= 1;
 484   if(dx > dw)  code |= 2;
 485   if(dy < -dw) code |= 4;
 486   if(dy > dw)  code |= 8;
 487   if(dz < -dw) code |= 16;
 488   if(dz > dw)  code |= 32;
 489   *ret = code;
 490 }
 491
 492 ===-------------------------------------------------------------------------===
 493
 494 %struct.B = type { i8, [3 x i8] }
 495
 496 define void @bar(%struct.B* %b) {
 497 entry:
 498         %tmp = bitcast %struct.B* %b to i32*              ; <uint*> [#uses=1]
 499         %tmp = load i32* %tmp          ; <uint> [#uses=1]
 500         %tmp3 = bitcast %struct.B* %b to i32*             ; <uint*> [#uses=1]
 501         %tmp4 = load i32* %tmp3                ; <uint> [#uses=1]
 502         %tmp8 = bitcast %struct.B* %b to i32*             ; <uint*> [#uses=2]
 503         %tmp9 = load i32* %tmp8                ; <uint> [#uses=1]
 504         %tmp4.mask17 = shl i32 %tmp4, i8 1          ; <uint> [#uses=1]
 505         %tmp1415 = and i32 %tmp4.mask17, 2147483648            ; <uint> [#uses=1]
 506         %tmp.masked = and i32 %tmp, 2147483648         ; <uint> [#uses=1]
 507         %tmp11 = or i32 %tmp1415, %tmp.masked          ; <uint> [#uses=1]
 508         %tmp12 = and i32 %tmp9, 2147483647             ; <uint> [#uses=1]
 509         %tmp13 = or i32 %tmp12, %tmp11         ; <uint> [#uses=1]
 510         store i32 %tmp13, i32* %tmp8
 511         ret void
 512 }
 513
 514 We emit:
 515
 516 _foo:
 517         lwz r2, 0(r3)
 518         slwi r4, r2, 1
 519         or r4, r4, r2
 520         rlwimi r2, r4, 0, 0, 0
 521         stw r2, 0(r3)
 522         blr
 523
 524 We could collapse a bunch of those ORs and ANDs and generate the following
 525 equivalent code:
 526
 527 _foo:
 528         lwz r2, 0(r3)
 529         rlwinm r4, r2, 1, 0, 0
 530         or r2, r2, r4
 531         stw r2, 0(r3)
 532         blr
 533
 534 ===-------------------------------------------------------------------------===
 535
 536 Consider a function like this:
 537
 538 float foo(float X) { return X + 1234.4123f; }
 539
 540 The FP constant ends up in the constant pool, so we need to get the LR register.
 541  This ends up producing code like this:
 542
 543 _foo:
 544 .LBB_foo_0:     ; entry
 545         mflr r11
 546 ***     stw r11, 8(r1)
 547         bl "L00000$pb"
 548 "L00000$pb":
 549         mflr r2
 550         addis r2, r2, ha16(.CPI_foo_0-"L00000$pb")
 551         lfs f0, lo16(.CPI_foo_0-"L00000$pb")(r2)
 552         fadds f1, f1, f0
 553 ***     lwz r11, 8(r1)
 554         mtlr r11
 555         blr
 556
 557 This is functional, but there is no reason to spill the LR register all the way
 558 to the stack (the two marked instrs): spilling it to a GPR is quite enough.
 559
 560 Implementing this will require some codegen improvements.  Nate writes:
 561
 562 "So basically what we need to support the "no stack frame save and restore" is a
 563 generalization of the LR optimization to "callee-save regs".
 564
 565 Currently, we have LR marked as a callee-save reg.  The register allocator sees
 566 that it's callee save, and spills it directly to the stack.
 567
 568 Ideally, something like this would happen:
 569
 570 LR would be in a separate register class from the GPRs. The class of LR would be
 571 marked "unspillable".  When the register allocator came across an unspillable
 572 reg, it would ask "what is the best class to copy this into that I *can* spill"
 573 If it gets a class back, which it will in this case (the gprs), it grabs a free
 574 register of that class.  If it is then later necessary to spill that reg, so be
 575 it.
 576
 577 ===-------------------------------------------------------------------------===
 578
 579 We compile this:
 580 int test(_Bool X) {
 581   return X ? 524288 : 0;
 582 }
 583
 584 to:
 585 _test:
 586         cmplwi cr0, r3, 0
 587         lis r2, 8
 588         li r3, 0
 589         beq cr0, LBB1_2 ;entry
 590 LBB1_1: ;entry
 591         mr r3, r2
 592 LBB1_2: ;entry
 593         blr
 594
 595 instead of:
 596 _test:
 597         addic r2,r3,-1
 598         subfe r0,r2,r3
 599         slwi r3,r0,19
 600         blr
 601
 602 This sort of thing occurs a lot due to globalopt.
 603
 604 ===-------------------------------------------------------------------------===
 605
 606 We compile:
 607
 608 define i32 @bar(i32 %x) nounwind readnone ssp {
 609 entry:
 610   %0 = icmp eq i32 %x, 0                          ; <i1> [#uses=1]
 611   %neg = sext i1 %0 to i32              ; <i32> [#uses=1]
 612   ret i32 %neg
 613 }
 614
 615 to:
 616
 617 _bar:
 618         cntlzw r2, r3
 619         slwi r2, r2, 26
 620         srawi r3, r2, 31
 621         blr
 622
 623 it would be better to produce:
 624
 625 _bar:
 626         addic r3,r3,-1
 627         subfe r3,r3,r3
 628         blr
 629
 630 ===-------------------------------------------------------------------------===
 631
 632 test/CodeGen/PowerPC/2007-03-24-cntlzd.ll compiles to:
 633
 634 __ZNK4llvm5APInt17countLeadingZerosEv:
 635         ld r2, 0(r3)
 636         cntlzd r2, r2
 637         or r2, r2, r2     <<-- silly.
 638         addi r3, r2, -64
 639         blr
 640
 641 The dead or is a 'truncate' from 64- to 32-bits.
 642
 643 ===-------------------------------------------------------------------------===
 644
 645 We generate horrible ppc code for this:
 646
 647 #define N  2000000
 648 double   a[N],c[N];
 649 void simpleloop() {
 650    int j;
 651    for (j=0; j<N; j++)
 652      c[j] = a[j];
 653 }
 654
 655 LBB1_1: ;bb
 656         lfdx f0, r3, r4
 657         addi r5, r5, 1                 ;; Extra IV for the exit value compare.
 658         stfdx f0, r2, r4
 659         addi r4, r4, 8
 660
 661         xoris r6, r5, 30               ;; This is due to a large immediate.
 662         cmplwi cr0, r6, 33920
 663         bne cr0, LBB1_1
 664
 665 //===---------------------------------------------------------------------===//
 666
 667 This:
 668         #include <algorithm>
 669         inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
 670         { return std::make_pair(a + b, a + b < a); }
 671         bool no_overflow(unsigned a, unsigned b)
 672         { return !full_add(a, b).second; }
 673
 674 Should compile to:
 675
 676 __Z11no_overflowjj:
 677         add r4,r3,r4
 678         subfc r3,r3,r4
 679         li r3,0
 680         adde r3,r3,r3
 681         blr
 682
 683 (or better) not:
 684
 685 __Z11no_overflowjj:
 686         add r2, r4, r3
 687         cmplw cr7, r2, r3
 688         mfcr r2
 689         rlwinm r2, r2, 29, 31, 31
 690         xori r3, r2, 1
 691         blr
 692
 693 //===---------------------------------------------------------------------===//
 694
 695 We compile some FP comparisons into an mfcr with two rlwinms and an or.  For
 696 example:
 697 #include <math.h>
 698 int test(double x, double y) { return islessequal(x, y);}
 699 int test2(double x, double y) {  return islessgreater(x, y);}
 700 int test3(double x, double y) {  return !islessequal(x, y);}
 701
 702 Compiles into (all three are similar, but the bits differ):
 703
 704 _test:
 705         fcmpu cr7, f1, f2
 706         mfcr r2
 707         rlwinm r3, r2, 29, 31, 31
 708         rlwinm r2, r2, 31, 31, 31
 709         or r3, r2, r3
 710         blr
 711
 712 GCC compiles this into:
 713
 714  _test:
 715         fcmpu cr7,f1,f2
 716         cror 30,28,30
 717         mfcr r3
 718         rlwinm r3,r3,31,1
 719         blr
 720
 721 which is more efficient and can use mfocr.  See PR642 for some more context.
 722
 723 //===---------------------------------------------------------------------===//
 724
 725 void foo(float *data, float d) {
 726    long i;
 727    for (i = 0; i < 8000; i++)
 728       data[i] = d;
 729 }
 730 void foo2(float *data, float d) {
 731    long i;
 732    data--;
 733    for (i = 0; i < 8000; i++) {
 734       data[1] = d;
 735       data++;
 736    }
 737 }
 738
 739 These compile to:
 740
 741 _foo:
 742         li r2, 0
 743 LBB1_1: ; bb
 744         addi r4, r2, 4
 745         stfsx f1, r3, r2
 746         cmplwi cr0, r4, 32000
 747         mr r2, r4
 748         bne cr0, LBB1_1 ; bb
 749         blr
 750 _foo2:
 751         li r2, 0
 752 LBB2_1: ; bb
 753         addi r4, r2, 4
 754         stfsx f1, r3, r2
 755         cmplwi cr0, r4, 32000
 756         mr r2, r4
 757         bne cr0, LBB2_1 ; bb
 758         blr
 759
 760 The 'mr' could be eliminated to folding the add into the cmp better.
 761
 762 //===---------------------------------------------------------------------===//
 763 Codegen for the following (low-probability) case deteriorated considerably
 764 when the correctness fixes for unordered comparisons went in (PR 642, 58871).
 765 It should be possible to recover the code quality described in the comments.
 766
 767 ; RUN: llvm-as < %s | llc -march=ppc32  | grep or | count 3
 768 ; This should produce one 'or' or 'cror' instruction per function.
 769
 770 ; RUN: llvm-as < %s | llc -march=ppc32  | grep mfcr | count 3
 771 ; PR2964
 772
 773 define i32 @test(double %x, double %y) nounwind  {
 774 entry:
 775         %tmp3 = fcmp ole double %x, %y          ; <i1> [#uses=1]
 776         %tmp345 = zext i1 %tmp3 to i32          ; <i32> [#uses=1]
 777         ret i32 %tmp345
 778 }
 779
 780 define i32 @test2(double %x, double %y) nounwind  {
 781 entry:
 782         %tmp3 = fcmp one double %x, %y          ; <i1> [#uses=1]
 783         %tmp345 = zext i1 %tmp3 to i32          ; <i32> [#uses=1]
 784         ret i32 %tmp345
 785 }
 786
 787 define i32 @test3(double %x, double %y) nounwind  {
 788 entry:
 789         %tmp3 = fcmp ugt double %x, %y          ; <i1> [#uses=1]
 790         %tmp34 = zext i1 %tmp3 to i32           ; <i32> [#uses=1]
 791         ret i32 %tmp34
 792 }
 793 //===----------------------------------------------------------------------===//
 794 ; RUN: llvm-as < %s | llc -march=ppc32 | not grep fneg
 795
 796 ; This could generate FSEL with appropriate flags (FSEL is not IEEE-safe, and
 797 ; should not be generated except with -enable-finite-only-fp-math or the like).
 798 ; With the correctness fixes for PR642 (58871) LowerSELECT_CC would need to
 799 ; recognize a more elaborate tree than a simple SETxx.
 800
 801 define double @test_FNEG_sel(double %A, double %B, double %C) {
 802         %D = fsub double -0.000000e+00, %A               ; <double> [#uses=1]
 803         %Cond = fcmp ugt double %D, -0.000000e+00               ; <i1> [#uses=1]
 804         %E = select i1 %Cond, double %B, double %C              ; <double> [#uses=1]
 805         ret double %E
 806 }
 807
 808 //===----------------------------------------------------------------------===//
 809 The save/restore sequence for CR in prolog/epilog is terrible:
 810 - Each CR subreg is saved individually, rather than doing one save as a unit.
 811 - On Darwin, the save is done after the decrement of SP, which means the offset
 812 from SP of the save slot can be too big for a store instruction, which means we
 813 need an additional register (currently hacked in 96015+96020; the solution there
 814 is correct, but poor).
 815 - On SVR4 the same thing can happen, and I don't think saving before the SP
 816 decrement is safe on that target, as there is no red zone.  This is currently
 817 broken AFAIK, although it's not a target I can exercise.
 818 The following demonstrates the problem:
 819 extern void bar(char *p);
 820 void foo() {
 821   char x[100000];
 822   bar(x);
 823   __asm__("" ::: "cr2");
 824 }