lib/Target/X86/README.txt

   1 //===---------------------------------------------------------------------===//
   2 // Random ideas for the X86 backend.
   3 //===---------------------------------------------------------------------===//
   4
   5 Missing features:
   6   - Support for SSE4: http://www.intel.com/software/penryn
   7 http://softwarecommunity.intel.com/isn/Downloads/Intel%20SSE4%20Programming%20Reference.pdf
   8   - support for 3DNow!
   9   - weird abis?
  10
  11 //===---------------------------------------------------------------------===//
  12
  13 CodeGen/X86/lea-3.ll:test3 should be a single LEA, not a shift/move.  The X86
  14 backend knows how to three-addressify this shift, but it appears the register
  15 allocator isn't even asking it to do so in this case.  We should investigate
  16 why this isn't happening, it could have significant impact on other important
  17 cases for X86 as well.
  18
  19 //===---------------------------------------------------------------------===//
  20
  21 This should be one DIV/IDIV instruction, not a libcall:
  22
  23 unsigned test(unsigned long long X, unsigned Y) {
  24         return X/Y;
  25 }
  26
  27 This can be done trivially with a custom legalizer.  What about overflow
  28 though?  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14224
  29
  30 //===---------------------------------------------------------------------===//
  31
  32 Improvements to the multiply -> shift/add algorithm:
  33 http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01590.html
  34
  35 //===---------------------------------------------------------------------===//
  36
  37 Improve code like this (occurs fairly frequently, e.g. in LLVM):
  38 long long foo(int x) { return 1LL << x; }
  39
  40 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01109.html
  41 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01128.html
  42 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01136.html
  43
  44 Another useful one would be  ~0ULL >> X and ~0ULL << X.
  45
  46 One better solution for 1LL << x is:
  47         xorl    %eax, %eax
  48         xorl    %edx, %edx
  49         testb   $32, %cl
  50         sete    %al
  51         setne   %dl
  52         sall    %cl, %eax
  53         sall    %cl, %edx
  54
  55 But that requires good 8-bit subreg support.
  56
  57 64-bit shifts (in general) expand to really bad code.  Instead of using
  58 cmovs, we should expand to a conditional branch like GCC produces.
  59
  60 //===---------------------------------------------------------------------===//
  61
  62 Compile this:
  63 _Bool f(_Bool a) { return a!=1; }
  64
  65 into:
  66         movzbl  %dil, %eax
  67         xorl    $1, %eax
  68         ret
  69
  70 //===---------------------------------------------------------------------===//
  71
  72 Some isel ideas:
  73
  74 1. Dynamic programming based approach when compile time if not an
  75    issue.
  76 2. Code duplication (addressing mode) during isel.
  77 3. Other ideas from "Register-Sensitive Selection, Duplication, and
  78    Sequencing of Instructions".
  79 4. Scheduling for reduced register pressure.  E.g. "Minimum Register
  80    Instruction Sequence Problem: Revisiting Optimal Code Generation for DAGs"
  81    and other related papers.
  82    http://citeseer.ist.psu.edu/govindarajan01minimum.html
  83
  84 //===---------------------------------------------------------------------===//
  85
  86 Should we promote i16 to i32 to avoid partial register update stalls?
  87
  88 //===---------------------------------------------------------------------===//
  89
  90 Leave any_extend as pseudo instruction and hint to register
  91 allocator. Delay codegen until post register allocation.
  92 Note. any_extend is now turned into an INSERT_SUBREG. We still need to teach
  93 the coalescer how to deal with it though.
  94
  95 //===---------------------------------------------------------------------===//
  96
  97 Count leading zeros and count trailing zeros:
  98
  99 int clz(int X) { return __builtin_clz(X); }
 100 int ctz(int X) { return __builtin_ctz(X); }
 101
 102 $ gcc t.c -S -o - -O3  -fomit-frame-pointer -masm=intel
 103 clz:
 104         bsr     %eax, DWORD PTR [%esp+4]
 105         xor     %eax, 31
 106         ret
 107 ctz:
 108         bsf     %eax, DWORD PTR [%esp+4]
 109         ret
 110
 111 however, check that these are defined for 0 and 32.  Our intrinsics are, GCC's
 112 aren't.
 113
 114 Another example (use predsimplify to eliminate a select):
 115
 116 int foo (unsigned long j) {
 117   if (j)
 118     return __builtin_ffs (j) - 1;
 119   else
 120     return 0;
 121 }
 122
 123 //===---------------------------------------------------------------------===//
 124
 125 It appears icc use push for parameter passing. Need to investigate.
 126
 127 //===---------------------------------------------------------------------===//
 128
 129 Only use inc/neg/not instructions on processors where they are faster than
 130 add/sub/xor.  They are slower on the P4 due to only updating some processor
 131 flags.
 132
 133 //===---------------------------------------------------------------------===//
 134
 135 The instruction selector sometimes misses folding a load into a compare.  The
 136 pattern is written as (cmp reg, (load p)).  Because the compare isn't
 137 commutative, it is not matched with the load on both sides.  The dag combiner
 138 should be made smart enough to cannonicalize the load into the RHS of a compare
 139 when it can invert the result of the compare for free.
 140
 141 //===---------------------------------------------------------------------===//
 142
 143 How about intrinsics? An example is:
 144   *res = _mm_mulhi_epu16(*A, _mm_mul_epu32(*B, *C));
 145
 146 compiles to
 147         pmuludq (%eax), %xmm0
 148         movl 8(%esp), %eax
 149         movdqa (%eax), %xmm1
 150         pmulhuw %xmm0, %xmm1
 151
 152 The transformation probably requires a X86 specific pass or a DAG combiner
 153 target specific hook.
 154
 155 //===---------------------------------------------------------------------===//
 156
 157 In many cases, LLVM generates code like this:
 158
 159 _test:
 160         movl 8(%esp), %eax
 161         cmpl %eax, 4(%esp)
 162         setl %al
 163         movzbl %al, %eax
 164         ret
 165
 166 on some processors (which ones?), it is more efficient to do this:
 167
 168 _test:
 169         movl 8(%esp), %ebx
 170         xor  %eax, %eax
 171         cmpl %ebx, 4(%esp)
 172         setl %al
 173         ret
 174
 175 Doing this correctly is tricky though, as the xor clobbers the flags.
 176
 177 //===---------------------------------------------------------------------===//
 178
 179 We should generate bts/btr/etc instructions on targets where they are cheap or
 180 when codesize is important.  e.g., for:
 181
 182 void setbit(int *target, int bit) {
 183     *target |= (1 << bit);
 184 }
 185 void clearbit(int *target, int bit) {
 186     *target &= ~(1 << bit);
 187 }
 188
 189 //===---------------------------------------------------------------------===//
 190
 191 Instead of the following for memset char*, 1, 10:
 192
 193         movl $16843009, 4(%edx)
 194         movl $16843009, (%edx)
 195         movw $257, 8(%edx)
 196
 197 It might be better to generate
 198
 199         movl $16843009, %eax
 200         movl %eax, 4(%edx)
 201         movl %eax, (%edx)
 202         movw al, 8(%edx)
 203
 204 when we can spare a register. It reduces code size.
 205
 206 //===---------------------------------------------------------------------===//
 207
 208 Evaluate what the best way to codegen sdiv X, (2^C) is.  For X/8, we currently
 209 get this:
 210
 211 int %test1(int %X) {
 212         %Y = div int %X, 8
 213         ret int %Y
 214 }
 215
 216 _test1:
 217         movl 4(%esp), %eax
 218         movl %eax, %ecx
 219         sarl $31, %ecx
 220         shrl $29, %ecx
 221         addl %ecx, %eax
 222         sarl $3, %eax
 223         ret
 224
 225 GCC knows several different ways to codegen it, one of which is this:
 226
 227 _test1:
 228         movl    4(%esp), %eax
 229         cmpl    $-1, %eax
 230         leal    7(%eax), %ecx
 231         cmovle  %ecx, %eax
 232         sarl    $3, %eax
 233         ret
 234
 235 which is probably slower, but it's interesting at least :)
 236
 237 //===---------------------------------------------------------------------===//
 238
 239 The first BB of this code:
 240
 241 declare bool %foo()
 242 int %bar() {
 243         %V = call bool %foo()
 244         br bool %V, label %T, label %F
 245 T:
 246         ret int 1
 247 F:
 248         call bool %foo()
 249         ret int 12
 250 }
 251
 252 compiles to:
 253
 254 _bar:
 255         subl $12, %esp
 256         call L_foo$stub
 257         xorb $1, %al
 258         testb %al, %al
 259         jne LBB_bar_2   # F
 260
 261 It would be better to emit "cmp %al, 1" than a xor and test.
 262
 263 //===---------------------------------------------------------------------===//
 264
 265 We are currently lowering large (1MB+) memmove/memcpy to rep/stosl and rep/movsl
 266 We should leave these as libcalls for everything over a much lower threshold,
 267 since libc is hand tuned for medium and large mem ops (avoiding RFO for large
 268 stores, TLB preheating, etc)
 269
 270 //===---------------------------------------------------------------------===//
 271
 272 Optimize this into something reasonable:
 273  x * copysign(1.0, y) * copysign(1.0, z)
 274
 275 //===---------------------------------------------------------------------===//
 276
 277 Optimize copysign(x, *y) to use an integer load from y.
 278
 279 //===---------------------------------------------------------------------===//
 280
 281 %X = weak global int 0
 282
 283 void %foo(int %N) {
 284         %N = cast int %N to uint
 285         %tmp.24 = setgt int %N, 0
 286         br bool %tmp.24, label %no_exit, label %return
 287
 288 no_exit:
 289         %indvar = phi uint [ 0, %entry ], [ %indvar.next, %no_exit ]
 290         %i.0.0 = cast uint %indvar to int
 291         volatile store int %i.0.0, int* %X
 292         %indvar.next = add uint %indvar, 1
 293         %exitcond = seteq uint %indvar.next, %N
 294         br bool %exitcond, label %return, label %no_exit
 295
 296 return:
 297         ret void
 298 }
 299
 300 compiles into:
 301
 302         .text
 303         .align  4
 304         .globl  _foo
 305 _foo:
 306         movl 4(%esp), %eax
 307         cmpl $1, %eax
 308         jl LBB_foo_4    # return
 309 LBB_foo_1:      # no_exit.preheader
 310         xorl %ecx, %ecx
 311 LBB_foo_2:      # no_exit
 312         movl L_X$non_lazy_ptr, %edx
 313         movl %ecx, (%edx)
 314         incl %ecx
 315         cmpl %eax, %ecx
 316         jne LBB_foo_2   # no_exit
 317 LBB_foo_3:      # return.loopexit
 318 LBB_foo_4:      # return
 319         ret
 320
 321 We should hoist "movl L_X$non_lazy_ptr, %edx" out of the loop after
 322 remateralization is implemented. This can be accomplished with 1) a target
 323 dependent LICM pass or 2) makeing SelectDAG represent the whole function.
 324
 325 //===---------------------------------------------------------------------===//
 326
 327 The following tests perform worse with LSR:
 328
 329 lambda, siod, optimizer-eval, ackermann, hash2, nestedloop, strcat, and Treesor.
 330
 331 //===---------------------------------------------------------------------===//
 332
 333 We are generating far worse code than gcc:
 334
 335 volatile short X, Y;
 336
 337 void foo(int N) {
 338   int i;
 339   for (i = 0; i < N; i++) { X = i; Y = i*4; }
 340 }
 341
 342 LBB1_1: # entry.bb_crit_edge
 343         xorl    %ecx, %ecx
 344         xorw    %dx, %dx
 345 LBB1_2: # bb
 346         movl    L_X$non_lazy_ptr, %esi
 347         movw    %cx, (%esi)
 348         movl    L_Y$non_lazy_ptr, %esi
 349         movw    %dx, (%esi)
 350         addw    $4, %dx
 351         incl    %ecx
 352         cmpl    %eax, %ecx
 353         jne     LBB1_2  # bb
 354
 355 vs.
 356
 357         xorl    %edx, %edx
 358         movl    L_X$non_lazy_ptr-"L00000000001$pb"(%ebx), %esi
 359         movl    L_Y$non_lazy_ptr-"L00000000001$pb"(%ebx), %ecx
 360 L4:
 361         movw    %dx, (%esi)
 362         leal    0(,%edx,4), %eax
 363         movw    %ax, (%ecx)
 364         addl    $1, %edx
 365         cmpl    %edx, %edi
 366         jne     L4
 367
 368 This is due to the lack of post regalloc LICM.
 369
 370 //===---------------------------------------------------------------------===//
 371
 372 Teach the coalescer to coalesce vregs of different register classes. e.g. FR32 /
 373 FR64 to VR128.
 374
 375 //===---------------------------------------------------------------------===//
 376
 377 mov $reg, 48(%esp)
 378 ...
 379 leal 48(%esp), %eax
 380 mov %eax, (%esp)
 381 call _foo
 382
 383 Obviously it would have been better for the first mov (or any op) to store
 384 directly %esp[0] if there are no other uses.
 385
 386 //===---------------------------------------------------------------------===//
 387
 388 Adding to the list of cmp / test poor codegen issues:
 389
 390 int test(__m128 *A, __m128 *B) {
 391   if (_mm_comige_ss(*A, *B))
 392     return 3;
 393   else
 394     return 4;
 395 }
 396
 397 _test:
 398         movl 8(%esp), %eax
 399         movaps (%eax), %xmm0
 400         movl 4(%esp), %eax
 401         movaps (%eax), %xmm1
 402         comiss %xmm0, %xmm1
 403         setae %al
 404         movzbl %al, %ecx
 405         movl $3, %eax
 406         movl $4, %edx
 407         cmpl $0, %ecx
 408         cmove %edx, %eax
 409         ret
 410
 411 Note the setae, movzbl, cmpl, cmove can be replaced with a single cmovae. There
 412 are a number of issues. 1) We are introducing a setcc between the result of the
 413 intrisic call and select. 2) The intrinsic is expected to produce a i32 value
 414 so a any extend (which becomes a zero extend) is added.
 415
 416 We probably need some kind of target DAG combine hook to fix this.
 417
 418 //===---------------------------------------------------------------------===//
 419
 420 We generate significantly worse code for this than GCC:
 421 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
 422 http://gcc.gnu.org/bugzilla/attachment.cgi?id=8701
 423
 424 There is also one case we do worse on PPC.
 425
 426 //===---------------------------------------------------------------------===//
 427
 428 If shorter, we should use things like:
 429 movzwl %ax, %eax
 430 instead of:
 431 andl $65535, %EAX
 432
 433 The former can also be used when the two-addressy nature of the 'and' would
 434 require a copy to be inserted (in X86InstrInfo::convertToThreeAddress).
 435
 436 //===---------------------------------------------------------------------===//
 437
 438 Another instruction selector deficiency:
 439
 440 void %bar() {
 441         %tmp = load int (int)** %foo
 442         %tmp = tail call int %tmp( int 3 )
 443         ret void
 444 }
 445
 446 _bar:
 447         subl $12, %esp
 448         movl L_foo$non_lazy_ptr, %eax
 449         movl (%eax), %eax
 450         call *%eax
 451         addl $12, %esp
 452         ret
 453
 454 The current isel scheme will not allow the load to be folded in the call since
 455 the load's chain result is read by the callseq_start.
 456
 457 //===---------------------------------------------------------------------===//
 458
 459 For this:
 460
 461 int test(int a)
 462 {
 463   return a * 3;
 464 }
 465
 466 We currently emits
 467         imull $3, 4(%esp), %eax
 468
 469 Perhaps this is what we really should generate is? Is imull three or four
 470 cycles? Note: ICC generates this:
 471         movl    4(%esp), %eax
 472         leal    (%eax,%eax,2), %eax
 473
 474 The current instruction priority is based on pattern complexity. The former is
 475 more "complex" because it folds a load so the latter will not be emitted.
 476
 477 Perhaps we should use AddedComplexity to give LEA32r a higher priority? We
 478 should always try to match LEA first since the LEA matching code does some
 479 estimate to determine whether the match is profitable.
 480
 481 However, if we care more about code size, then imull is better. It's two bytes
 482 shorter than movl + leal.
 483
 484 //===---------------------------------------------------------------------===//
 485
 486 Implement CTTZ, CTLZ with bsf and bsr. GCC produces:
 487
 488 int ctz_(unsigned X) { return __builtin_ctz(X); }
 489 int clz_(unsigned X) { return __builtin_clz(X); }
 490 int ffs_(unsigned X) { return __builtin_ffs(X); }
 491
 492 _ctz_:
 493         bsfl    4(%esp), %eax
 494         ret
 495 _clz_:
 496         bsrl    4(%esp), %eax
 497         xorl    $31, %eax
 498         ret
 499 _ffs_:
 500         movl    $-1, %edx
 501         bsfl    4(%esp), %eax
 502         cmove   %edx, %eax
 503         addl    $1, %eax
 504         ret
 505
 506 //===---------------------------------------------------------------------===//
 507
 508 It appears gcc place string data with linkonce linkage in
 509 .section __TEXT,__const_coal,coalesced instead of
 510 .section __DATA,__const_coal,coalesced.
 511 Take a look at darwin.h, there are other Darwin assembler directives that we
 512 do not make use of.
 513
 514 //===---------------------------------------------------------------------===//
 515
 516 define i32 @foo(i32* %a, i32 %t) {
 517 entry:
 518         br label %cond_true
 519
 520 cond_true:              ; preds = %cond_true, %entry
 521         %x.0.0 = phi i32 [ 0, %entry ], [ %tmp9, %cond_true ]           ; <i32> [#uses=3]
 522         %t_addr.0.0 = phi i32 [ %t, %entry ], [ %tmp7, %cond_true ]             ; <i32> [#uses=1]
 523         %tmp2 = getelementptr i32* %a, i32 %x.0.0               ; <i32*> [#uses=1]
 524         %tmp3 = load i32* %tmp2         ; <i32> [#uses=1]
 525         %tmp5 = add i32 %t_addr.0.0, %x.0.0             ; <i32> [#uses=1]
 526         %tmp7 = add i32 %tmp5, %tmp3            ; <i32> [#uses=2]
 527         %tmp9 = add i32 %x.0.0, 1               ; <i32> [#uses=2]
 528         %tmp = icmp sgt i32 %tmp9, 39           ; <i1> [#uses=1]
 529         br i1 %tmp, label %bb12, label %cond_true
 530
 531 bb12:           ; preds = %cond_true
 532         ret i32 %tmp7
 533 }
 534 is pessimized by -loop-reduce and -indvars
 535
 536 //===---------------------------------------------------------------------===//
 537
 538 u32 to float conversion improvement:
 539
 540 float uint32_2_float( unsigned u ) {
 541   float fl = (int) (u & 0xffff);
 542   float fh = (int) (u >> 16);
 543   fh *= 0x1.0p16f;
 544   return fh + fl;
 545 }
 546
 547 00000000        subl    $0x04,%esp
 548 00000003        movl    0x08(%esp,1),%eax
 549 00000007        movl    %eax,%ecx
 550 00000009        shrl    $0x10,%ecx
 551 0000000c        cvtsi2ss        %ecx,%xmm0
 552 00000010        andl    $0x0000ffff,%eax
 553 00000015        cvtsi2ss        %eax,%xmm1
 554 00000019        mulss   0x00000078,%xmm0
 555 00000021        addss   %xmm1,%xmm0
 556 00000025        movss   %xmm0,(%esp,1)
 557 0000002a        flds    (%esp,1)
 558 0000002d        addl    $0x04,%esp
 559 00000030        ret
 560
 561 //===---------------------------------------------------------------------===//
 562
 563 When using fastcc abi, align stack slot of argument of type double on 8 byte
 564 boundary to improve performance.
 565
 566 //===---------------------------------------------------------------------===//
 567
 568 Codegen:
 569
 570 int f(int a, int b) {
 571   if (a == 4 || a == 6)
 572     b++;
 573   return b;
 574 }
 575
 576
 577 as:
 578
 579 or eax, 2
 580 cmp eax, 6
 581 jz label
 582
 583 //===---------------------------------------------------------------------===//
 584
 585 GCC's ix86_expand_int_movcc function (in i386.c) has a ton of interesting
 586 simplifications for integer "x cmp y ? a : b".  For example, instead of:
 587
 588 int G;
 589 void f(int X, int Y) {
 590   G = X < 0 ? 14 : 13;
 591 }
 592
 593 compiling to:
 594
 595 _f:
 596         movl $14, %eax
 597         movl $13, %ecx
 598         movl 4(%esp), %edx
 599         testl %edx, %edx
 600         cmovl %eax, %ecx
 601         movl %ecx, _G
 602         ret
 603
 604 it could be:
 605 _f:
 606         movl    4(%esp), %eax
 607         sarl    $31, %eax
 608         notl    %eax
 609         addl    $14, %eax
 610         movl    %eax, _G
 611         ret
 612
 613 etc.
 614
 615 Another is:
 616 int usesbb(unsigned int a, unsigned int b) {
 617        return (a < b ? -1 : 0);
 618 }
 619 to:
 620 _usesbb:
 621         movl    8(%esp), %eax
 622         cmpl    %eax, 4(%esp)
 623         sbbl    %eax, %eax
 624         ret
 625
 626 instead of:
 627 _usesbb:
 628         xorl    %eax, %eax
 629         movl    8(%esp), %ecx
 630         cmpl    %ecx, 4(%esp)
 631         movl    $4294967295, %ecx
 632         cmovb   %ecx, %eax
 633         ret
 634
 635 //===---------------------------------------------------------------------===//
 636
 637 Currently we don't have elimination of redundant stack manipulations. Consider
 638 the code:
 639
 640 int %main() {
 641 entry:
 642         call fastcc void %test1( )
 643         call fastcc void %test2( sbyte* cast (void ()* %test1 to sbyte*) )
 644         ret int 0
 645 }
 646
 647 declare fastcc void %test1()
 648
 649 declare fastcc void %test2(sbyte*)
 650
 651
 652 This currently compiles to:
 653
 654         subl $16, %esp
 655         call _test5
 656         addl $12, %esp
 657         subl $16, %esp
 658         movl $_test5, (%esp)
 659         call _test6
 660         addl $12, %esp
 661
 662 The add\sub pair is really unneeded here.
 663
 664 //===---------------------------------------------------------------------===//
 665
 666 Consider the expansion of:
 667
 668 define i32 @test3(i32 %X) {
 669         %tmp1 = urem i32 %X, 255
 670         ret i32 %tmp1
 671 }
 672
 673 Currently it compiles to:
 674
 675 ...
 676         movl $2155905153, %ecx
 677         movl 8(%esp), %esi
 678         movl %esi, %eax
 679         mull %ecx
 680 ...
 681
 682 This could be "reassociated" into:
 683
 684         movl $2155905153, %eax
 685         movl 8(%esp), %ecx
 686         mull %ecx
 687
 688 to avoid the copy.  In fact, the existing two-address stuff would do this
 689 except that mul isn't a commutative 2-addr instruction.  I guess this has
 690 to be done at isel time based on the #uses to mul?
 691
 692 //===---------------------------------------------------------------------===//
 693
 694 Make sure the instruction which starts a loop does not cross a cacheline
 695 boundary. This requires knowning the exact length of each machine instruction.
 696 That is somewhat complicated, but doable. Example 256.bzip2:
 697
 698 In the new trace, the hot loop has an instruction which crosses a cacheline
 699 boundary.  In addition to potential cache misses, this can't help decoding as I
 700 imagine there has to be some kind of complicated decoder reset and realignment
 701 to grab the bytes from the next cacheline.
 702
 703 532  532 0x3cfc movb     (1809(%esp, %esi), %bl   <<<--- spans 2 64 byte lines
 704 942  942 0x3d03 movl     %dh, (1809(%esp, %esi)
 705 937  937 0x3d0a incl     %esi
 706 3    3   0x3d0b cmpb     %bl, %dl
 707 27   27  0x3d0d jnz      0x000062db <main+11707>
 708
 709 //===---------------------------------------------------------------------===//
 710
 711 In c99 mode, the preprocessor doesn't like assembly comments like #TRUNCATE.
 712
 713 //===---------------------------------------------------------------------===//
 714
 715 This could be a single 16-bit load.
 716
 717 int f(char *p) {
 718     if ((p[0] == 1) & (p[1] == 2)) return 1;
 719     return 0;
 720 }
 721
 722 //===---------------------------------------------------------------------===//
 723
 724 We should inline lrintf and probably other libc functions.
 725
 726 //===---------------------------------------------------------------------===//
 727
 728 Start using the flags more.  For example, compile:
 729
 730 int add_zf(int *x, int y, int a, int b) {
 731      if ((*x += y) == 0)
 732           return a;
 733      else
 734           return b;
 735 }
 736
 737 to:
 738        addl    %esi, (%rdi)
 739        movl    %edx, %eax
 740        cmovne  %ecx, %eax
 741        ret
 742 instead of:
 743
 744 _add_zf:
 745         addl (%rdi), %esi
 746         movl %esi, (%rdi)
 747         testl %esi, %esi
 748         cmove %edx, %ecx
 749         movl %ecx, %eax
 750         ret
 751
 752 and:
 753
 754 int add_zf(int *x, int y, int a, int b) {
 755      if ((*x + y) < 0)
 756           return a;
 757      else
 758           return b;
 759 }
 760
 761 to:
 762
 763 add_zf:
 764         addl    (%rdi), %esi
 765         movl    %edx, %eax
 766         cmovns  %ecx, %eax
 767         ret
 768
 769 instead of:
 770
 771 _add_zf:
 772         addl (%rdi), %esi
 773         testl %esi, %esi
 774         cmovs %edx, %ecx
 775         movl %ecx, %eax
 776         ret
 777
 778 //===---------------------------------------------------------------------===//
 779
 780 These two functions have identical effects:
 781
 782 unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return i;}
 783 unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
 784
 785 We currently compile them to:
 786
 787 _f:
 788         movl 4(%esp), %eax
 789         movl %eax, %ecx
 790         incl %ecx
 791         movl 8(%esp), %edx
 792         cmpl %edx, %ecx
 793         jne LBB1_2      #UnifiedReturnBlock
 794 LBB1_1: #cond_true
 795         addl $2, %eax
 796         ret
 797 LBB1_2: #UnifiedReturnBlock
 798         movl %ecx, %eax
 799         ret
 800 _f2:
 801         movl 4(%esp), %eax
 802         movl %eax, %ecx
 803         incl %ecx
 804         cmpl 8(%esp), %ecx
 805         sete %cl
 806         movzbl %cl, %ecx
 807         leal 1(%ecx,%eax), %eax
 808         ret
 809
 810 both of which are inferior to GCC's:
 811
 812 _f:
 813         movl    4(%esp), %edx
 814         leal    1(%edx), %eax
 815         addl    $2, %edx
 816         cmpl    8(%esp), %eax
 817         cmove   %edx, %eax
 818         ret
 819 _f2:
 820         movl    4(%esp), %eax
 821         addl    $1, %eax
 822         xorl    %edx, %edx
 823         cmpl    8(%esp), %eax
 824         sete    %dl
 825         addl    %edx, %eax
 826         ret
 827
 828 //===---------------------------------------------------------------------===//
 829
 830 This code:
 831
 832 void test(int X) {
 833   if (X) abort();
 834 }
 835
 836 is currently compiled to:
 837
 838 _test:
 839         subl $12, %esp
 840         cmpl $0, 16(%esp)
 841         jne LBB1_1
 842         addl $12, %esp
 843         ret
 844 LBB1_1:
 845         call L_abort$stub
 846
 847 It would be better to produce:
 848
 849 _test:
 850         subl $12, %esp
 851         cmpl $0, 16(%esp)
 852         jne L_abort$stub
 853         addl $12, %esp
 854         ret
 855
 856 This can be applied to any no-return function call that takes no arguments etc.
 857 Alternatively, the stack save/restore logic could be shrink-wrapped, producing
 858 something like this:
 859
 860 _test:
 861         cmpl $0, 4(%esp)
 862         jne LBB1_1
 863         ret
 864 LBB1_1:
 865         subl $12, %esp
 866         call L_abort$stub
 867
 868 Both are useful in different situations.  Finally, it could be shrink-wrapped
 869 and tail called, like this:
 870
 871 _test:
 872         cmpl $0, 4(%esp)
 873         jne LBB1_1
 874         ret
 875 LBB1_1:
 876         pop %eax   # realign stack.
 877         call L_abort$stub
 878
 879 Though this probably isn't worth it.
 880
 881 //===---------------------------------------------------------------------===//
 882
 883 We need to teach the codegen to convert two-address INC instructions to LEA
 884 when the flags are dead (likewise dec).  For example, on X86-64, compile:
 885
 886 int foo(int A, int B) {
 887   return A+1;
 888 }
 889
 890 to:
 891
 892 _foo:
 893         leal    1(%edi), %eax
 894         ret
 895
 896 instead of:
 897
 898 _foo:
 899         incl %edi
 900         movl %edi, %eax
 901         ret
 902
 903 Another example is:
 904
 905 ;; X's live range extends beyond the shift, so the register allocator
 906 ;; cannot coalesce it with Y.  Because of this, a copy needs to be
 907 ;; emitted before the shift to save the register value before it is
 908 ;; clobbered.  However, this copy is not needed if the register
 909 ;; allocator turns the shift into an LEA.  This also occurs for ADD.
 910
 911 ; Check that the shift gets turned into an LEA.
 912 ; RUN: llvm-as < %s | llc -march=x86 -x86-asm-syntax=intel | \
 913 ; RUN:   not grep {mov E.X, E.X}
 914
 915 @G = external global i32                ; <i32*> [#uses=3]
 916
 917 define i32 @test1(i32 %X, i32 %Y) {
 918         %Z = add i32 %X, %Y             ; <i32> [#uses=1]
 919         volatile store i32 %Y, i32* @G
 920         volatile store i32 %Z, i32* @G
 921         ret i32 %X
 922 }
 923
 924 define i32 @test2(i32 %X) {
 925         %Z = add i32 %X, 1              ; <i32> [#uses=1]
 926         volatile store i32 %Z, i32* @G
 927         ret i32 %X
 928 }
 929
 930 //===---------------------------------------------------------------------===//
 931
 932 Sometimes it is better to codegen subtractions from a constant (e.g. 7-x) with
 933 a neg instead of a sub instruction.  Consider:
 934
 935 int test(char X) { return 7-X; }
 936
 937 we currently produce:
 938 _test:
 939         movl $7, %eax
 940         movsbl 4(%esp), %ecx
 941         subl %ecx, %eax
 942         ret
 943
 944 We would use one fewer register if codegen'd as:
 945
 946         movsbl 4(%esp), %eax
 947         neg %eax
 948         add $7, %eax
 949         ret
 950
 951 Note that this isn't beneficial if the load can be folded into the sub.  In
 952 this case, we want a sub:
 953
 954 int test(int X) { return 7-X; }
 955 _test:
 956         movl $7, %eax
 957         subl 4(%esp), %eax
 958         ret
 959
 960 //===---------------------------------------------------------------------===//
 961
 962 This is a "commutable two-address" register coallescing deficiency:
 963
 964 define <4 x float> @test1(<4 x float> %V) {
 965 entry:
 966         %tmp8 = shufflevector <4 x float> %V, <4 x float> undef,
 967                                         <4 x i32> < i32 3, i32 2, i32 1, i32 0 >
 968         %add = add <4 x float> %tmp8, %V
 969         ret <4 x float> %add
 970 }
 971
 972 this codegens to:
 973
 974 _test1:
 975         pshufd  $27, %xmm0, %xmm1
 976         addps   %xmm0, %xmm1
 977         movaps  %xmm1, %xmm0
 978         ret
 979
 980 instead of:
 981
 982 _test1:
 983         pshufd  $27, %xmm0, %xmm1
 984         addps   %xmm1, %xmm0
 985         ret
 986
 987 //===---------------------------------------------------------------------===//
 988
 989 Leaf functions that require one 4-byte spill slot have a prolog like this:
 990
 991 _foo:
 992         pushl   %esi
 993         subl    $4, %esp
 994 ...
 995 and an epilog like this:
 996         addl    $4, %esp
 997         popl    %esi
 998         ret
 999
1000 It would be smaller, and potentially faster, to push eax on entry and to
1001 pop into a dummy register instead of using addl/subl of esp.  Just don't pop
1002 into any return registers :)
1003
1004 //===---------------------------------------------------------------------===//
1005
1006 The X86 backend should fold (branch (or (setcc, setcc))) into multiple
1007 branches.  We generate really poor code for:
1008
1009 double testf(double a) {
1010        return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
1011 }
1012
1013 For example, the entry BB is:
1014
1015 _testf:
1016         subl    $20, %esp
1017         pxor    %xmm0, %xmm0
1018         movsd   24(%esp), %xmm1
1019         ucomisd %xmm0, %xmm1
1020         setnp   %al
1021         sete    %cl
1022         testb   %cl, %al
1023         jne     LBB1_5  # UnifiedReturnBlock
1024 LBB1_1: # cond_true
1025
1026
1027 it would be better to replace the last four instructions with:
1028
1029         jp LBB1_1
1030         je LBB1_5
1031 LBB1_1:
1032
1033 We also codegen the inner ?: into a diamond:
1034
1035        cvtss2sd        LCPI1_0(%rip), %xmm2
1036         cvtss2sd        LCPI1_1(%rip), %xmm3
1037         ucomisd %xmm1, %xmm0
1038         ja      LBB1_3  # cond_true
1039 LBB1_2: # cond_true
1040         movapd  %xmm3, %xmm2
1041 LBB1_3: # cond_true
1042         movapd  %xmm2, %xmm0
1043         ret
1044
1045 We should sink the load into xmm3 into the LBB1_2 block.  This should
1046 be pretty easy, and will nuke all the copies.
1047
1048 //===---------------------------------------------------------------------===//
1049
1050 This:
1051         #include <algorithm>
1052         inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
1053         { return std::make_pair(a + b, a + b < a); }
1054         bool no_overflow(unsigned a, unsigned b)
1055         { return !full_add(a, b).second; }
1056
1057 Should compile to:
1058
1059
1060         _Z11no_overflowjj:
1061                 addl    %edi, %esi
1062                 setae   %al
1063                 ret
1064
1065 on x86-64, not:
1066
1067 __Z11no_overflowjj:
1068         addl    %edi, %esi
1069         cmpl    %edi, %esi
1070         setae   %al
1071         movzbl  %al, %eax
1072         ret
1073
1074
1075 //===---------------------------------------------------------------------===//
1076
1077 Re-materialize MOV32r0 etc. with xor instead of changing them to moves if the
1078 condition register is dead. xor reg reg is shorter than mov reg, #0.
1079
1080 //===---------------------------------------------------------------------===//
1081
1082 We aren't matching RMW instructions aggressively
1083 enough.  Here's a reduced testcase (more in PR1160):
1084
1085 define void @test(i32* %huge_ptr, i32* %target_ptr) {
1086         %A = load i32* %huge_ptr                ; <i32> [#uses=1]
1087         %B = load i32* %target_ptr              ; <i32> [#uses=1]
1088         %C = or i32 %A, %B              ; <i32> [#uses=1]
1089         store i32 %C, i32* %target_ptr
1090         ret void
1091 }
1092
1093 $ llvm-as < t.ll | llc -march=x86-64
1094
1095 _test:
1096         movl (%rdi), %eax
1097         orl (%rsi), %eax
1098         movl %eax, (%rsi)
1099         ret
1100
1101 That should be something like:
1102
1103 _test:
1104         movl (%rdi), %eax
1105         orl %eax, (%rsi)
1106         ret
1107
1108 //===---------------------------------------------------------------------===//
1109
1110 The following code:
1111
1112 bb114.preheader:                ; preds = %cond_next94
1113         %tmp231232 = sext i16 %tmp62 to i32             ; <i32> [#uses=1]
1114         %tmp233 = sub i32 32, %tmp231232                ; <i32> [#uses=1]
1115         %tmp245246 = sext i16 %tmp65 to i32             ; <i32> [#uses=1]
1116         %tmp252253 = sext i16 %tmp68 to i32             ; <i32> [#uses=1]
1117         %tmp254 = sub i32 32, %tmp252253                ; <i32> [#uses=1]
1118         %tmp553554 = bitcast i16* %tmp37 to i8*         ; <i8*> [#uses=2]
1119         %tmp583584 = sext i16 %tmp98 to i32             ; <i32> [#uses=1]
1120         %tmp585 = sub i32 32, %tmp583584                ; <i32> [#uses=1]
1121         %tmp614615 = sext i16 %tmp101 to i32            ; <i32> [#uses=1]
1122         %tmp621622 = sext i16 %tmp104 to i32            ; <i32> [#uses=1]
1123         %tmp623 = sub i32 32, %tmp621622                ; <i32> [#uses=1]
1124         br label %bb114
1125
1126 produces:
1127
1128 LBB3_5: # bb114.preheader
1129         movswl  -68(%ebp), %eax
1130         movl    $32, %ecx
1131         movl    %ecx, -80(%ebp)
1132         subl    %eax, -80(%ebp)
1133         movswl  -52(%ebp), %eax
1134         movl    %ecx, -84(%ebp)
1135         subl    %eax, -84(%ebp)
1136         movswl  -70(%ebp), %eax
1137         movl    %ecx, -88(%ebp)
1138         subl    %eax, -88(%ebp)
1139         movswl  -50(%ebp), %eax
1140         subl    %eax, %ecx
1141         movl    %ecx, -76(%ebp)
1142         movswl  -42(%ebp), %eax
1143         movl    %eax, -92(%ebp)
1144         movswl  -66(%ebp), %eax
1145         movl    %eax, -96(%ebp)
1146         movw    $0, -98(%ebp)
1147
1148 This appears to be bad because the RA is not folding the store to the stack
1149 slot into the movl.  The above instructions could be:
1150         movl    $32, -80(%ebp)
1151 ...
1152         movl    $32, -84(%ebp)
1153 ...
1154 This seems like a cross between remat and spill folding.
1155
1156 This has redundant subtractions of %eax from a stack slot. However, %ecx doesn't
1157 change, so we could simply subtract %eax from %ecx first and then use %ecx (or
1158 vice-versa).
1159
1160 //===---------------------------------------------------------------------===//
1161
1162 For this code:
1163
1164 cond_next603:           ; preds = %bb493, %cond_true336, %cond_next599
1165         %v.21050.1 = phi i32 [ %v.21050.0, %cond_next599 ], [ %tmp344, %cond_true336 ], [ %v.2, %bb493 ]                ; <i32> [#uses=1]
1166         %maxz.21051.1 = phi i32 [ %maxz.21051.0, %cond_next599 ], [ 0, %cond_true336 ], [ %maxz.2, %bb493 ]             ; <i32> [#uses=2]
1167         %cnt.01055.1 = phi i32 [ %cnt.01055.0, %cond_next599 ], [ 0, %cond_true336 ], [ %cnt.0, %bb493 ]                ; <i32> [#uses=2]
1168         %byteptr.9 = phi i8* [ %byteptr.12, %cond_next599 ], [ %byteptr.0, %cond_true336 ], [ %byteptr.10, %bb493 ]             ; <i8*> [#uses=9]
1169         %bitptr.6 = phi i32 [ %tmp5571104.1, %cond_next599 ], [ %tmp4921049, %cond_true336 ], [ %bitptr.7, %bb493 ]             ; <i32> [#uses=4]
1170         %source.5 = phi i32 [ %tmp602, %cond_next599 ], [ %source.0, %cond_true336 ], [ %source.6, %bb493 ]             ; <i32> [#uses=7]
1171         %tmp606 = getelementptr %struct.const_tables* @tables, i32 0, i32 0, i32 %cnt.01055.1           ; <i8*> [#uses=1]
1172         %tmp607 = load i8* %tmp606, align 1             ; <i8> [#uses=1]
1173
1174 We produce this:
1175
1176 LBB4_70:        # cond_next603
1177         movl    -20(%ebp), %esi
1178         movl    L_tables$non_lazy_ptr-"L4$pb"(%esi), %esi
1179
1180 However, ICC caches this information before the loop and produces this:
1181
1182         movl      88(%esp), %eax                                #481.12
1183
1184 //===---------------------------------------------------------------------===//
1185
1186 This code:
1187
1188         %tmp659 = icmp slt i16 %tmp654, 0               ; <i1> [#uses=1]
1189         br i1 %tmp659, label %cond_true662, label %cond_next715
1190
1191 produces this:
1192
1193         testw   %cx, %cx
1194         movswl  %cx, %esi
1195         jns     LBB4_109        # cond_next715
1196
1197 Shark tells us that using %cx in the testw instruction is sub-optimal. It
1198 suggests using the 32-bit register (which is what ICC uses).
1199
1200 //===---------------------------------------------------------------------===//
1201
1202 We compile this:
1203
1204 void compare (long long foo) {
1205   if (foo < 4294967297LL)
1206     abort();
1207 }
1208
1209 to:
1210
1211 _compare:
1212         subl    $12, %esp
1213         cmpl    $0, 16(%esp)
1214         setne   %al
1215         movzbw  %al, %ax
1216         cmpl    $1, 20(%esp)
1217         setg    %cl
1218         movzbw  %cl, %cx
1219         cmove   %ax, %cx
1220         movw    %cx, %ax
1221         testb   $1, %al
1222         je      LBB1_2  # cond_true
1223
1224 (also really horrible code on ppc).  This is due to the expand code for 64-bit
1225 compares.  GCC produces multiple branches, which is much nicer:
1226
1227 _compare:
1228         pushl   %ebp
1229         movl    %esp, %ebp
1230         subl    $8, %esp
1231         movl    8(%ebp), %eax
1232         movl    12(%ebp), %edx
1233         subl    $1, %edx
1234         jg     L5
1235 L7:
1236         jl      L4
1237         cmpl    $0, %eax
1238         jbe      L4
1239 L5:
1240
1241 //===---------------------------------------------------------------------===//
1242
1243 Tail call optimization improvements: Tail call optimization currently
1244 pushes all arguments on the top of the stack (their normal place for
1245 non-tail call optimized calls) that source from the callers arguments
1246 or  that source from a virtual register (also possibly sourcing from
1247 callers arguments).
1248 This is done to prevent overwriting of parameters (see example
1249 below) that might be used later.
1250
1251 example:
1252
1253 int callee(int32, int64);
1254 int caller(int32 arg1, int32 arg2) {
1255   int64 local = arg2 * 2;
1256   return callee(arg2, (int64)local);
1257 }
1258
1259 [arg1]          [!arg2 no longer valid since we moved local onto it]
1260 [arg2]      ->  [(int64)
1261 [RETADDR]        local  ]
1262
1263 Moving arg1 onto the stack slot of callee function would overwrite
1264 arg2 of the caller.
1265
1266 Possible optimizations:
1267
1268
1269  - Analyse the actual parameters of the callee to see which would
1270    overwrite a caller parameter which is used by the callee and only
1271    push them onto the top of the stack.
1272
1273    int callee (int32 arg1, int32 arg2);
1274    int caller (int32 arg1, int32 arg2) {
1275        return callee(arg1,arg2);
1276    }
1277
1278    Here we don't need to write any variables to the top of the stack
1279    since they don't overwrite each other.
1280
1281    int callee (int32 arg1, int32 arg2);
1282    int caller (int32 arg1, int32 arg2) {
1283        return callee(arg2,arg1);
1284    }
1285
1286    Here we need to push the arguments because they overwrite each
1287    other.
1288
1289 //===---------------------------------------------------------------------===//
1290
1291 main ()
1292 {
1293   int i = 0;
1294   unsigned long int z = 0;
1295
1296   do {
1297     z -= 0x00004000;
1298     i++;
1299     if (i > 0x00040000)
1300       abort ();
1301   } while (z > 0);
1302   exit (0);
1303 }
1304
1305 gcc compiles this to:
1306
1307 _main:
1308         subl    $28, %esp
1309         xorl    %eax, %eax
1310         jmp     L2
1311 L3:
1312         cmpl    $262144, %eax
1313         je      L10
1314 L2:
1315         addl    $1, %eax
1316         cmpl    $262145, %eax
1317         jne     L3
1318         call    L_abort$stub
1319 L10:
1320         movl    $0, (%esp)
1321         call    L_exit$stub
1322
1323 llvm:
1324
1325 _main:
1326         subl    $12, %esp
1327         movl    $1, %eax
1328         movl    $16384, %ecx
1329 LBB1_1: # bb
1330         cmpl    $262145, %eax
1331         jge     LBB1_4  # cond_true
1332 LBB1_2: # cond_next
1333         incl    %eax
1334         addl    $4294950912, %ecx
1335         cmpl    $16384, %ecx
1336         jne     LBB1_1  # bb
1337 LBB1_3: # bb11
1338         xorl    %eax, %eax
1339         addl    $12, %esp
1340         ret
1341 LBB1_4: # cond_true
1342         call    L_abort$stub
1343
1344 1. LSR should rewrite the first cmp with induction variable %ecx.
1345 2. DAG combiner should fold
1346         leal    1(%eax), %edx
1347         cmpl    $262145, %edx
1348    =>
1349         cmpl    $262144, %eax
1350
1351 //===---------------------------------------------------------------------===//
1352
1353 define i64 @test(double %X) {
1354         %Y = fptosi double %X to i64
1355         ret i64 %Y
1356 }
1357
1358 compiles to:
1359
1360 _test:
1361         subl    $20, %esp
1362         movsd   24(%esp), %xmm0
1363         movsd   %xmm0, 8(%esp)
1364         fldl    8(%esp)
1365         fisttpll        (%esp)
1366         movl    4(%esp), %edx
1367         movl    (%esp), %eax
1368         addl    $20, %esp
1369         #FP_REG_KILL
1370         ret
1371
1372 This should just fldl directly from the input stack slot.
1373
1374 //===---------------------------------------------------------------------===//
1375
1376 This code:
1377 int foo (int x) { return (x & 65535) | 255; }
1378
1379 Should compile into:
1380
1381 _foo:
1382         movzwl  4(%esp), %eax
1383         orb     $-1, %al           ;; 'orl 255' is also fine :)
1384         ret
1385
1386 instead of:
1387 _foo:
1388         movl    $255, %eax
1389         orl     4(%esp), %eax
1390         andl    $65535, %eax
1391         ret
1392
1393 //===---------------------------------------------------------------------===//
1394
1395 We're missing an obvious fold of a load into imul:
1396
1397 int test(long a, long b) { return a * b; }
1398
1399 LLVM produces:
1400 _test:
1401         movl    4(%esp), %ecx
1402         movl    8(%esp), %eax
1403         imull   %ecx, %eax
1404         ret
1405
1406 vs:
1407 _test:
1408         movl    8(%esp), %eax
1409         imull   4(%esp), %eax
1410         ret
1411
1412 //===---------------------------------------------------------------------===//
1413
1414 We can fold a store into "zeroing a reg".  Instead of:
1415
1416 xorl    %eax, %eax
1417 movl    %eax, 124(%esp)
1418
1419 we should get:
1420
1421 movl    $0, 124(%esp)
1422
1423 if the flags of the xor are dead.
1424
1425 Likewise, we isel "x<<1" into "add reg,reg".  If reg is spilled, this should
1426 be folded into: shl [mem], 1
1427
1428 //===---------------------------------------------------------------------===//
1429
1430 This testcase misses a read/modify/write opportunity (from PR1425):
1431
1432 void vertical_decompose97iH1(int *b0, int *b1, int *b2, int width){
1433     int i;
1434     for(i=0; i<width; i++)
1435         b1[i] += (1*(b0[i] + b2[i])+0)>>0;
1436 }
1437
1438 We compile it down to:
1439
1440 LBB1_2: # bb
1441         movl    (%esi,%edi,4), %ebx
1442         addl    (%ecx,%edi,4), %ebx
1443         addl    (%edx,%edi,4), %ebx
1444         movl    %ebx, (%ecx,%edi,4)
1445         incl    %edi
1446         cmpl    %eax, %edi
1447         jne     LBB1_2  # bb
1448
1449 the inner loop should add to the memory location (%ecx,%edi,4), saving
1450 a mov.  Something like:
1451
1452         movl    (%esi,%edi,4), %ebx
1453         addl    (%edx,%edi,4), %ebx
1454         addl    %ebx, (%ecx,%edi,4)
1455
1456 Here is another interesting example:
1457
1458 void vertical_compose97iH1(int *b0, int *b1, int *b2, int width){
1459     int i;
1460     for(i=0; i<width; i++)
1461         b1[i] -= (1*(b0[i] + b2[i])+0)>>0;
1462 }
1463
1464 We miss the r/m/w opportunity here by using 2 subs instead of an add+sub[mem]:
1465
1466 LBB9_2: # bb
1467         movl    (%ecx,%edi,4), %ebx
1468         subl    (%esi,%edi,4), %ebx
1469         subl    (%edx,%edi,4), %ebx
1470         movl    %ebx, (%ecx,%edi,4)
1471         incl    %edi
1472         cmpl    %eax, %edi
1473         jne     LBB9_2  # bb
1474
1475 Additionally, LSR should rewrite the exit condition of these loops to use
1476 a stride-4 IV, would would allow all the scales in the loop to go away.
1477 This would result in smaller code and more efficient microops.
1478
1479 //===---------------------------------------------------------------------===//
1480
1481 In SSE mode, we turn abs and neg into a load from the constant pool plus a xor
1482 or and instruction, for example:
1483
1484         xorpd   LCPI1_0, %xmm2
1485
1486 However, if xmm2 gets spilled, we end up with really ugly code like this:
1487
1488         movsd   (%esp), %xmm0
1489         xorpd   LCPI1_0, %xmm0
1490         movsd   %xmm0, (%esp)
1491
1492 Since we 'know' that this is a 'neg', we can actually "fold" the spill into
1493 the neg/abs instruction, turning it into an *integer* operation, like this:
1494
1495         xorl 2147483648, [mem+4]     ## 2147483648 = (1 << 31)
1496
1497 you could also use xorb, but xorl is less likely to lead to a partial register
1498 stall.  Here is a contrived testcase:
1499
1500 double a, b, c;
1501 void test(double *P) {
1502   double X = *P;
1503   a = X;
1504   bar();
1505   X = -X;
1506   b = X;
1507   bar();
1508   c = X;
1509 }
1510
1511 //===---------------------------------------------------------------------===//
1512
1513 handling llvm.memory.barrier on pre SSE2 cpus
1514
1515 should generate:
1516 lock ; mov %esp, %esp
1517
1518 //===---------------------------------------------------------------------===//