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 Consider this:
 439
 440 typedef struct pair { float A, B; } pair;
 441 void pairtest(pair P, float *FP) {
 442         *FP = P.A+P.B;
 443 }
 444
 445 We currently generate this code with llvmgcc4:
 446
 447 _pairtest:
 448         movl 8(%esp), %eax
 449         movl 4(%esp), %ecx
 450         movd %eax, %xmm0
 451         movd %ecx, %xmm1
 452         addss %xmm0, %xmm1
 453         movl 12(%esp), %eax
 454         movss %xmm1, (%eax)
 455         ret
 456
 457 we should be able to generate:
 458 _pairtest:
 459         movss 4(%esp), %xmm0
 460         movl 12(%esp), %eax
 461         addss 8(%esp), %xmm0
 462         movss %xmm0, (%eax)
 463         ret
 464
 465 The issue is that llvmgcc4 is forcing the struct to memory, then passing it as
 466 integer chunks.  It does this so that structs like {short,short} are passed in
 467 a single 32-bit integer stack slot.  We should handle the safe cases above much
 468 nicer, while still handling the hard cases.
 469
 470 While true in general, in this specific case we could do better by promoting
 471 load int + bitcast to float -> load fload.  This basically needs alignment info,
 472 the code is already implemented (but disabled) in dag combine).
 473
 474 //===---------------------------------------------------------------------===//
 475
 476 Another instruction selector deficiency:
 477
 478 void %bar() {
 479         %tmp = load int (int)** %foo
 480         %tmp = tail call int %tmp( int 3 )
 481         ret void
 482 }
 483
 484 _bar:
 485         subl $12, %esp
 486         movl L_foo$non_lazy_ptr, %eax
 487         movl (%eax), %eax
 488         call *%eax
 489         addl $12, %esp
 490         ret
 491
 492 The current isel scheme will not allow the load to be folded in the call since
 493 the load's chain result is read by the callseq_start.
 494
 495 //===---------------------------------------------------------------------===//
 496
 497 For this:
 498
 499 int test(int a)
 500 {
 501   return a * 3;
 502 }
 503
 504 We currently emits
 505         imull $3, 4(%esp), %eax
 506
 507 Perhaps this is what we really should generate is? Is imull three or four
 508 cycles? Note: ICC generates this:
 509         movl    4(%esp), %eax
 510         leal    (%eax,%eax,2), %eax
 511
 512 The current instruction priority is based on pattern complexity. The former is
 513 more "complex" because it folds a load so the latter will not be emitted.
 514
 515 Perhaps we should use AddedComplexity to give LEA32r a higher priority? We
 516 should always try to match LEA first since the LEA matching code does some
 517 estimate to determine whether the match is profitable.
 518
 519 However, if we care more about code size, then imull is better. It's two bytes
 520 shorter than movl + leal.
 521
 522 //===---------------------------------------------------------------------===//
 523
 524 Implement CTTZ, CTLZ with bsf and bsr. GCC produces:
 525
 526 int ctz_(unsigned X) { return __builtin_ctz(X); }
 527 int clz_(unsigned X) { return __builtin_clz(X); }
 528 int ffs_(unsigned X) { return __builtin_ffs(X); }
 529
 530 _ctz_:
 531         bsfl    4(%esp), %eax
 532         ret
 533 _clz_:
 534         bsrl    4(%esp), %eax
 535         xorl    $31, %eax
 536         ret
 537 _ffs_:
 538         movl    $-1, %edx
 539         bsfl    4(%esp), %eax
 540         cmove   %edx, %eax
 541         addl    $1, %eax
 542         ret
 543
 544 //===---------------------------------------------------------------------===//
 545
 546 It appears gcc place string data with linkonce linkage in
 547 .section __TEXT,__const_coal,coalesced instead of
 548 .section __DATA,__const_coal,coalesced.
 549 Take a look at darwin.h, there are other Darwin assembler directives that we
 550 do not make use of.
 551
 552 //===---------------------------------------------------------------------===//
 553
 554 int %foo(int* %a, int %t) {
 555 entry:
 556         br label %cond_true
 557
 558 cond_true:              ; preds = %cond_true, %entry
 559         %x.0.0 = phi int [ 0, %entry ], [ %tmp9, %cond_true ]
 560         %t_addr.0.0 = phi int [ %t, %entry ], [ %tmp7, %cond_true ]
 561         %tmp2 = getelementptr int* %a, int %x.0.0
 562         %tmp3 = load int* %tmp2         ; <int> [#uses=1]
 563         %tmp5 = add int %t_addr.0.0, %x.0.0             ; <int> [#uses=1]
 564         %tmp7 = add int %tmp5, %tmp3            ; <int> [#uses=2]
 565         %tmp9 = add int %x.0.0, 1               ; <int> [#uses=2]
 566         %tmp = setgt int %tmp9, 39              ; <bool> [#uses=1]
 567         br bool %tmp, label %bb12, label %cond_true
 568
 569 bb12:           ; preds = %cond_true
 570         ret int %tmp7
 571 }
 572
 573 is pessimized by -loop-reduce and -indvars
 574
 575 //===---------------------------------------------------------------------===//
 576
 577 u32 to float conversion improvement:
 578
 579 float uint32_2_float( unsigned u ) {
 580   float fl = (int) (u & 0xffff);
 581   float fh = (int) (u >> 16);
 582   fh *= 0x1.0p16f;
 583   return fh + fl;
 584 }
 585
 586 00000000        subl    $0x04,%esp
 587 00000003        movl    0x08(%esp,1),%eax
 588 00000007        movl    %eax,%ecx
 589 00000009        shrl    $0x10,%ecx
 590 0000000c        cvtsi2ss        %ecx,%xmm0
 591 00000010        andl    $0x0000ffff,%eax
 592 00000015        cvtsi2ss        %eax,%xmm1
 593 00000019        mulss   0x00000078,%xmm0
 594 00000021        addss   %xmm1,%xmm0
 595 00000025        movss   %xmm0,(%esp,1)
 596 0000002a        flds    (%esp,1)
 597 0000002d        addl    $0x04,%esp
 598 00000030        ret
 599
 600 //===---------------------------------------------------------------------===//
 601
 602 When using fastcc abi, align stack slot of argument of type double on 8 byte
 603 boundary to improve performance.
 604
 605 //===---------------------------------------------------------------------===//
 606
 607 Codegen:
 608
 609 int f(int a, int b) {
 610   if (a == 4 || a == 6)
 611     b++;
 612   return b;
 613 }
 614
 615
 616 as:
 617
 618 or eax, 2
 619 cmp eax, 6
 620 jz label
 621
 622 //===---------------------------------------------------------------------===//
 623
 624 GCC's ix86_expand_int_movcc function (in i386.c) has a ton of interesting
 625 simplifications for integer "x cmp y ? a : b".  For example, instead of:
 626
 627 int G;
 628 void f(int X, int Y) {
 629   G = X < 0 ? 14 : 13;
 630 }
 631
 632 compiling to:
 633
 634 _f:
 635         movl $14, %eax
 636         movl $13, %ecx
 637         movl 4(%esp), %edx
 638         testl %edx, %edx
 639         cmovl %eax, %ecx
 640         movl %ecx, _G
 641         ret
 642
 643 it could be:
 644 _f:
 645         movl    4(%esp), %eax
 646         sarl    $31, %eax
 647         notl    %eax
 648         addl    $14, %eax
 649         movl    %eax, _G
 650         ret
 651
 652 etc.
 653
 654 Another is:
 655 int usesbb(unsigned int a, unsigned int b) {
 656        return (a < b ? -1 : 0);
 657 }
 658 to:
 659 _usesbb:
 660         movl    8(%esp), %eax
 661         cmpl    %eax, 4(%esp)
 662         sbbl    %eax, %eax
 663         ret
 664
 665 instead of:
 666 _usesbb:
 667         xorl    %eax, %eax
 668         movl    8(%esp), %ecx
 669         cmpl    %ecx, 4(%esp)
 670         movl    $4294967295, %ecx
 671         cmovb   %ecx, %eax
 672         ret
 673
 674 //===---------------------------------------------------------------------===//
 675
 676 Currently we don't have elimination of redundant stack manipulations. Consider
 677 the code:
 678
 679 int %main() {
 680 entry:
 681         call fastcc void %test1( )
 682         call fastcc void %test2( sbyte* cast (void ()* %test1 to sbyte*) )
 683         ret int 0
 684 }
 685
 686 declare fastcc void %test1()
 687
 688 declare fastcc void %test2(sbyte*)
 689
 690
 691 This currently compiles to:
 692
 693         subl $16, %esp
 694         call _test5
 695         addl $12, %esp
 696         subl $16, %esp
 697         movl $_test5, (%esp)
 698         call _test6
 699         addl $12, %esp
 700
 701 The add\sub pair is really unneeded here.
 702
 703 //===---------------------------------------------------------------------===//
 704
 705 Consider the expansion of:
 706
 707 uint %test3(uint %X) {
 708         %tmp1 = rem uint %X, 255
 709         ret uint %tmp1
 710 }
 711
 712 Currently it compiles to:
 713
 714 ...
 715         movl $2155905153, %ecx
 716         movl 8(%esp), %esi
 717         movl %esi, %eax
 718         mull %ecx
 719 ...
 720
 721 This could be "reassociated" into:
 722
 723         movl $2155905153, %eax
 724         movl 8(%esp), %ecx
 725         mull %ecx
 726
 727 to avoid the copy.  In fact, the existing two-address stuff would do this
 728 except that mul isn't a commutative 2-addr instruction.  I guess this has
 729 to be done at isel time based on the #uses to mul?
 730
 731 //===---------------------------------------------------------------------===//
 732
 733 Make sure the instruction which starts a loop does not cross a cacheline
 734 boundary. This requires knowning the exact length of each machine instruction.
 735 That is somewhat complicated, but doable. Example 256.bzip2:
 736
 737 In the new trace, the hot loop has an instruction which crosses a cacheline
 738 boundary.  In addition to potential cache misses, this can't help decoding as I
 739 imagine there has to be some kind of complicated decoder reset and realignment
 740 to grab the bytes from the next cacheline.
 741
 742 532  532 0x3cfc movb     (1809(%esp, %esi), %bl   <<<--- spans 2 64 byte lines
 743 942  942 0x3d03 movl     %dh, (1809(%esp, %esi)
 744 937  937 0x3d0a incl     %esi
 745 3    3   0x3d0b cmpb     %bl, %dl
 746 27   27  0x3d0d jnz      0x000062db <main+11707>
 747
 748 //===---------------------------------------------------------------------===//
 749
 750 In c99 mode, the preprocessor doesn't like assembly comments like #TRUNCATE.
 751
 752 //===---------------------------------------------------------------------===//
 753
 754 This could be a single 16-bit load.
 755
 756 int f(char *p) {
 757     if ((p[0] == 1) & (p[1] == 2)) return 1;
 758     return 0;
 759 }
 760
 761 //===---------------------------------------------------------------------===//
 762
 763 We should inline lrintf and probably other libc functions.
 764
 765 //===---------------------------------------------------------------------===//
 766
 767 Start using the flags more.  For example, compile:
 768
 769 int add_zf(int *x, int y, int a, int b) {
 770      if ((*x += y) == 0)
 771           return a;
 772      else
 773           return b;
 774 }
 775
 776 to:
 777        addl    %esi, (%rdi)
 778        movl    %edx, %eax
 779        cmovne  %ecx, %eax
 780        ret
 781 instead of:
 782
 783 _add_zf:
 784         addl (%rdi), %esi
 785         movl %esi, (%rdi)
 786         testl %esi, %esi
 787         cmove %edx, %ecx
 788         movl %ecx, %eax
 789         ret
 790
 791 and:
 792
 793 int add_zf(int *x, int y, int a, int b) {
 794      if ((*x + y) < 0)
 795           return a;
 796      else
 797           return b;
 798 }
 799
 800 to:
 801
 802 add_zf:
 803         addl    (%rdi), %esi
 804         movl    %edx, %eax
 805         cmovns  %ecx, %eax
 806         ret
 807
 808 instead of:
 809
 810 _add_zf:
 811         addl (%rdi), %esi
 812         testl %esi, %esi
 813         cmovs %edx, %ecx
 814         movl %ecx, %eax
 815         ret
 816
 817 //===---------------------------------------------------------------------===//
 818
 819 This:
 820 #include <math.h>
 821 int foo(double X) { return isnan(X); }
 822
 823 compiles to (-m64):
 824
 825 _foo:
 826         pxor %xmm1, %xmm1
 827         ucomisd %xmm1, %xmm0
 828         setp %al
 829         movzbl %al, %eax
 830         ret
 831
 832 the pxor is not needed, we could compare the value against itself.
 833
 834 //===---------------------------------------------------------------------===//
 835
 836 These two functions have identical effects:
 837
 838 unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return i;}
 839 unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
 840
 841 We currently compile them to:
 842
 843 _f:
 844         movl 4(%esp), %eax
 845         movl %eax, %ecx
 846         incl %ecx
 847         movl 8(%esp), %edx
 848         cmpl %edx, %ecx
 849         jne LBB1_2      #UnifiedReturnBlock
 850 LBB1_1: #cond_true
 851         addl $2, %eax
 852         ret
 853 LBB1_2: #UnifiedReturnBlock
 854         movl %ecx, %eax
 855         ret
 856 _f2:
 857         movl 4(%esp), %eax
 858         movl %eax, %ecx
 859         incl %ecx
 860         cmpl 8(%esp), %ecx
 861         sete %cl
 862         movzbl %cl, %ecx
 863         leal 1(%ecx,%eax), %eax
 864         ret
 865
 866 both of which are inferior to GCC's:
 867
 868 _f:
 869         movl    4(%esp), %edx
 870         leal    1(%edx), %eax
 871         addl    $2, %edx
 872         cmpl    8(%esp), %eax
 873         cmove   %edx, %eax
 874         ret
 875 _f2:
 876         movl    4(%esp), %eax
 877         addl    $1, %eax
 878         xorl    %edx, %edx
 879         cmpl    8(%esp), %eax
 880         sete    %dl
 881         addl    %edx, %eax
 882         ret
 883
 884 //===---------------------------------------------------------------------===//
 885
 886 This code:
 887
 888 void test(int X) {
 889   if (X) abort();
 890 }
 891
 892 is currently compiled to:
 893
 894 _test:
 895         subl $12, %esp
 896         cmpl $0, 16(%esp)
 897         jne LBB1_1
 898         addl $12, %esp
 899         ret
 900 LBB1_1:
 901         call L_abort$stub
 902
 903 It would be better to produce:
 904
 905 _test:
 906         subl $12, %esp
 907         cmpl $0, 16(%esp)
 908         jne L_abort$stub
 909         addl $12, %esp
 910         ret
 911
 912 This can be applied to any no-return function call that takes no arguments etc.
 913 Alternatively, the stack save/restore logic could be shrink-wrapped, producing
 914 something like this:
 915
 916 _test:
 917         cmpl $0, 4(%esp)
 918         jne LBB1_1
 919         ret
 920 LBB1_1:
 921         subl $12, %esp
 922         call L_abort$stub
 923
 924 Both are useful in different situations.  Finally, it could be shrink-wrapped
 925 and tail called, like this:
 926
 927 _test:
 928         cmpl $0, 4(%esp)
 929         jne LBB1_1
 930         ret
 931 LBB1_1:
 932         pop %eax   # realign stack.
 933         call L_abort$stub
 934
 935 Though this probably isn't worth it.
 936
 937 //===---------------------------------------------------------------------===//
 938
 939 We need to teach the codegen to convert two-address INC instructions to LEA
 940 when the flags are dead (likewise dec).  For example, on X86-64, compile:
 941
 942 int foo(int A, int B) {
 943   return A+1;
 944 }
 945
 946 to:
 947
 948 _foo:
 949         leal    1(%edi), %eax
 950         ret
 951
 952 instead of:
 953
 954 _foo:
 955         incl %edi
 956         movl %edi, %eax
 957         ret
 958
 959 Another example is:
 960
 961 ;; X's live range extends beyond the shift, so the register allocator
 962 ;; cannot coalesce it with Y.  Because of this, a copy needs to be
 963 ;; emitted before the shift to save the register value before it is
 964 ;; clobbered.  However, this copy is not needed if the register
 965 ;; allocator turns the shift into an LEA.  This also occurs for ADD.
 966
 967 ; Check that the shift gets turned into an LEA.
 968 ; RUN: llvm-upgrade < %s | llvm-as | llc -march=x86 -x86-asm-syntax=intel | \
 969 ; RUN:   not grep {mov E.X, E.X}
 970
 971 %G = external global int
 972
 973 int %test1(int %X, int %Y) {
 974         %Z = add int %X, %Y
 975         volatile store int %Y, int* %G
 976         volatile store int %Z, int* %G
 977         ret int %X
 978 }
 979
 980 int %test2(int %X) {
 981         %Z = add int %X, 1  ;; inc
 982         volatile store int %Z, int* %G
 983         ret int %X
 984 }
 985
 986 //===---------------------------------------------------------------------===//
 987
 988 Sometimes it is better to codegen subtractions from a constant (e.g. 7-x) with
 989 a neg instead of a sub instruction.  Consider:
 990
 991 int test(char X) { return 7-X; }
 992
 993 we currently produce:
 994 _test:
 995         movl $7, %eax
 996         movsbl 4(%esp), %ecx
 997         subl %ecx, %eax
 998         ret
 999
1000 We would use one fewer register if codegen'd as:
1001
1002         movsbl 4(%esp), %eax
1003         neg %eax
1004         add $7, %eax
1005         ret
1006
1007 Note that this isn't beneficial if the load can be folded into the sub.  In
1008 this case, we want a sub:
1009
1010 int test(int X) { return 7-X; }
1011 _test:
1012         movl $7, %eax
1013         subl 4(%esp), %eax
1014         ret
1015
1016 //===---------------------------------------------------------------------===//
1017
1018 For code like:
1019 phi (undef, x)
1020
1021 We get an implicit def on the undef side. If the phi is spilled, we then get:
1022 implicitdef xmm1
1023 store xmm1 -> stack
1024
1025 It should be possible to teach the x86 backend to "fold" the store into the
1026 implicitdef, which just deletes the implicit def.
1027
1028 These instructions should go away:
1029 #IMPLICIT_DEF %xmm1
1030 movaps %xmm1, 192(%esp)
1031 movaps %xmm1, 224(%esp)
1032 movaps %xmm1, 176(%esp)
1033
1034 //===---------------------------------------------------------------------===//
1035
1036 This is a "commutable two-address" register coallescing deficiency:
1037
1038 define <4 x float> @test1(<4 x float> %V) {
1039 entry:
1040         %tmp8 = shufflevector <4 x float> %V, <4 x float> undef,
1041                                         <4 x i32> < i32 3, i32 2, i32 1, i32 0 >
1042         %add = add <4 x float> %tmp8, %V
1043         ret <4 x float> %add
1044 }
1045
1046 this codegens to:
1047
1048 _test1:
1049         pshufd  $27, %xmm0, %xmm1
1050         addps   %xmm0, %xmm1
1051         movaps  %xmm1, %xmm0
1052         ret
1053
1054 instead of:
1055
1056 _test1:
1057         pshufd  $27, %xmm0, %xmm1
1058         addps   %xmm1, %xmm0
1059         ret
1060
1061 //===---------------------------------------------------------------------===//
1062
1063 Leaf functions that require one 4-byte spill slot have a prolog like this:
1064
1065 _foo:
1066         pushl   %esi
1067         subl    $4, %esp
1068 ...
1069 and an epilog like this:
1070         addl    $4, %esp
1071         popl    %esi
1072         ret
1073
1074 It would be smaller, and potentially faster, to push eax on entry and to
1075 pop into a dummy register instead of using addl/subl of esp.  Just don't pop
1076 into any return registers :)
1077
1078 //===---------------------------------------------------------------------===//
1079
1080 The X86 backend should fold (branch (or (setcc, setcc))) into multiple
1081 branches.  We generate really poor code for:
1082
1083 double testf(double a) {
1084        return a == 0.0 ? 0.0 : (a > 0.0 ? 1.0 : -1.0);
1085 }
1086
1087 For example, the entry BB is:
1088
1089 _testf:
1090         subl    $20, %esp
1091         pxor    %xmm0, %xmm0
1092         movsd   24(%esp), %xmm1
1093         ucomisd %xmm0, %xmm1
1094         setnp   %al
1095         sete    %cl
1096         testb   %cl, %al
1097         jne     LBB1_5  # UnifiedReturnBlock
1098 LBB1_1: # cond_true
1099
1100
1101 it would be better to replace the last four instructions with:
1102
1103         jp LBB1_1
1104         je LBB1_5
1105 LBB1_1:
1106
1107 We also codegen the inner ?: into a diamond:
1108
1109        cvtss2sd        LCPI1_0(%rip), %xmm2
1110         cvtss2sd        LCPI1_1(%rip), %xmm3
1111         ucomisd %xmm1, %xmm0
1112         ja      LBB1_3  # cond_true
1113 LBB1_2: # cond_true
1114         movapd  %xmm3, %xmm2
1115 LBB1_3: # cond_true
1116         movapd  %xmm2, %xmm0
1117         ret
1118
1119 We should sink the load into xmm3 into the LBB1_2 block.  This should
1120 be pretty easy, and will nuke all the copies.
1121
1122 //===---------------------------------------------------------------------===//
1123
1124 This:
1125         #include <algorithm>
1126         inline std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
1127         { return std::make_pair(a + b, a + b < a); }
1128         bool no_overflow(unsigned a, unsigned b)
1129         { return !full_add(a, b).second; }
1130
1131 Should compile to:
1132
1133
1134         _Z11no_overflowjj:
1135                 addl    %edi, %esi
1136                 setae   %al
1137                 ret
1138
1139 on x86-64, not:
1140
1141 __Z11no_overflowjj:
1142         addl    %edi, %esi
1143         cmpl    %edi, %esi
1144         setae   %al
1145         movzbl  %al, %eax
1146         ret
1147
1148
1149 //===---------------------------------------------------------------------===//
1150
1151 Re-materialize MOV32r0 etc. with xor instead of changing them to moves if the
1152 condition register is dead. xor reg reg is shorter than mov reg, #0.
1153
1154 //===---------------------------------------------------------------------===//
1155
1156 We aren't matching RMW instructions aggressively
1157 enough.  Here's a reduced testcase (more in PR1160):
1158
1159 define void @test(i32* %huge_ptr, i32* %target_ptr) {
1160         %A = load i32* %huge_ptr                ; <i32> [#uses=1]
1161         %B = load i32* %target_ptr              ; <i32> [#uses=1]
1162         %C = or i32 %A, %B              ; <i32> [#uses=1]
1163         store i32 %C, i32* %target_ptr
1164         ret void
1165 }
1166
1167 $ llvm-as < t.ll | llc -march=x86-64
1168
1169 _test:
1170         movl (%rdi), %eax
1171         orl (%rsi), %eax
1172         movl %eax, (%rsi)
1173         ret
1174
1175 That should be something like:
1176
1177 _test:
1178         movl (%rdi), %eax
1179         orl %eax, (%rsi)
1180         ret
1181
1182 //===---------------------------------------------------------------------===//
1183
1184 The following code:
1185
1186 bb114.preheader:                ; preds = %cond_next94
1187         %tmp231232 = sext i16 %tmp62 to i32             ; <i32> [#uses=1]
1188         %tmp233 = sub i32 32, %tmp231232                ; <i32> [#uses=1]
1189         %tmp245246 = sext i16 %tmp65 to i32             ; <i32> [#uses=1]
1190         %tmp252253 = sext i16 %tmp68 to i32             ; <i32> [#uses=1]
1191         %tmp254 = sub i32 32, %tmp252253                ; <i32> [#uses=1]
1192         %tmp553554 = bitcast i16* %tmp37 to i8*         ; <i8*> [#uses=2]
1193         %tmp583584 = sext i16 %tmp98 to i32             ; <i32> [#uses=1]
1194         %tmp585 = sub i32 32, %tmp583584                ; <i32> [#uses=1]
1195         %tmp614615 = sext i16 %tmp101 to i32            ; <i32> [#uses=1]
1196         %tmp621622 = sext i16 %tmp104 to i32            ; <i32> [#uses=1]
1197         %tmp623 = sub i32 32, %tmp621622                ; <i32> [#uses=1]
1198         br label %bb114
1199
1200 produces:
1201
1202 LBB3_5: # bb114.preheader
1203         movswl  -68(%ebp), %eax
1204         movl    $32, %ecx
1205         movl    %ecx, -80(%ebp)
1206         subl    %eax, -80(%ebp)
1207         movswl  -52(%ebp), %eax
1208         movl    %ecx, -84(%ebp)
1209         subl    %eax, -84(%ebp)
1210         movswl  -70(%ebp), %eax
1211         movl    %ecx, -88(%ebp)
1212         subl    %eax, -88(%ebp)
1213         movswl  -50(%ebp), %eax
1214         subl    %eax, %ecx
1215         movl    %ecx, -76(%ebp)
1216         movswl  -42(%ebp), %eax
1217         movl    %eax, -92(%ebp)
1218         movswl  -66(%ebp), %eax
1219         movl    %eax, -96(%ebp)
1220         movw    $0, -98(%ebp)
1221
1222 This appears to be bad because the RA is not folding the store to the stack
1223 slot into the movl.  The above instructions could be:
1224         movl    $32, -80(%ebp)
1225 ...
1226         movl    $32, -84(%ebp)
1227 ...
1228 This seems like a cross between remat and spill folding.
1229
1230 This has redundant subtractions of %eax from a stack slot. However, %ecx doesn't
1231 change, so we could simply subtract %eax from %ecx first and then use %ecx (or
1232 vice-versa).
1233
1234 //===---------------------------------------------------------------------===//
1235
1236 For this code:
1237
1238 cond_next603:           ; preds = %bb493, %cond_true336, %cond_next599
1239         %v.21050.1 = phi i32 [ %v.21050.0, %cond_next599 ], [ %tmp344, %cond_true336 ], [ %v.2, %bb493 ]                ; <i32> [#uses=1]
1240         %maxz.21051.1 = phi i32 [ %maxz.21051.0, %cond_next599 ], [ 0, %cond_true336 ], [ %maxz.2, %bb493 ]             ; <i32> [#uses=2]
1241         %cnt.01055.1 = phi i32 [ %cnt.01055.0, %cond_next599 ], [ 0, %cond_true336 ], [ %cnt.0, %bb493 ]                ; <i32> [#uses=2]
1242         %byteptr.9 = phi i8* [ %byteptr.12, %cond_next599 ], [ %byteptr.0, %cond_true336 ], [ %byteptr.10, %bb493 ]             ; <i8*> [#uses=9]
1243         %bitptr.6 = phi i32 [ %tmp5571104.1, %cond_next599 ], [ %tmp4921049, %cond_true336 ], [ %bitptr.7, %bb493 ]             ; <i32> [#uses=4]
1244         %source.5 = phi i32 [ %tmp602, %cond_next599 ], [ %source.0, %cond_true336 ], [ %source.6, %bb493 ]             ; <i32> [#uses=7]
1245         %tmp606 = getelementptr %struct.const_tables* @tables, i32 0, i32 0, i32 %cnt.01055.1           ; <i8*> [#uses=1]
1246         %tmp607 = load i8* %tmp606, align 1             ; <i8> [#uses=1]
1247
1248 We produce this:
1249
1250 LBB4_70:        # cond_next603
1251         movl    -20(%ebp), %esi
1252         movl    L_tables$non_lazy_ptr-"L4$pb"(%esi), %esi
1253
1254 However, ICC caches this information before the loop and produces this:
1255
1256         movl      88(%esp), %eax                                #481.12
1257
1258 //===---------------------------------------------------------------------===//
1259
1260 This code:
1261
1262         %tmp659 = icmp slt i16 %tmp654, 0               ; <i1> [#uses=1]
1263         br i1 %tmp659, label %cond_true662, label %cond_next715
1264
1265 produces this:
1266
1267         testw   %cx, %cx
1268         movswl  %cx, %esi
1269         jns     LBB4_109        # cond_next715
1270
1271 Shark tells us that using %cx in the testw instruction is sub-optimal. It
1272 suggests using the 32-bit register (which is what ICC uses).
1273
1274 //===---------------------------------------------------------------------===//
1275
1276 rdar://5506677 - We compile this:
1277
1278 define i32 @foo(double %x) {
1279         %x14 = bitcast double %x to i64         ; <i64> [#uses=1]
1280         %tmp713 = trunc i64 %x14 to i32         ; <i32> [#uses=1]
1281         %tmp8 = and i32 %tmp713, 2147483647             ; <i32> [#uses=1]
1282         ret i32 %tmp8
1283 }
1284
1285 to:
1286
1287 _foo:
1288         subl    $12, %esp
1289         fldl    16(%esp)
1290         fstpl   (%esp)
1291         movl    $2147483647, %eax
1292         andl    (%esp), %eax
1293         addl    $12, %esp
1294         #FP_REG_KILL
1295         ret
1296
1297 It would be much better to eliminate the fldl/fstpl by folding the bitcast
1298 into the load SDNode.  That would give us:
1299
1300 _foo:
1301         movl    $2147483647, %eax
1302         andl    4(%esp), %eax
1303         ret
1304
1305 //===---------------------------------------------------------------------===//
1306
1307 We compile this:
1308
1309 void compare (long long foo) {
1310   if (foo < 4294967297LL)
1311     abort();
1312 }
1313
1314 to:
1315
1316 _compare:
1317         subl    $12, %esp
1318         cmpl    $0, 16(%esp)
1319         setne   %al
1320         movzbw  %al, %ax
1321         cmpl    $1, 20(%esp)
1322         setg    %cl
1323         movzbw  %cl, %cx
1324         cmove   %ax, %cx
1325         movw    %cx, %ax
1326         testb   $1, %al
1327         je      LBB1_2  # cond_true
1328
1329 (also really horrible code on ppc).  This is due to the expand code for 64-bit
1330 compares.  GCC produces multiple branches, which is much nicer:
1331
1332 _compare:
1333         pushl   %ebp
1334         movl    %esp, %ebp
1335         subl    $8, %esp
1336         movl    8(%ebp), %eax
1337         movl    12(%ebp), %edx
1338         subl    $1, %edx
1339         jg     L5
1340 L7:
1341         jl      L4
1342         cmpl    $0, %eax
1343         jbe      L4
1344 L5:
1345
1346 //===---------------------------------------------------------------------===//
1347
1348 Tail call optimization improvements: Tail call optimization currently
1349 pushes all arguments on the top of the stack (their normal place for
1350 non-tail call optimized calls) before moving them to actual stack
1351 slot. This is done to prevent overwriting of parameters (see example
1352 below) that might be used, since the arguments of the callee
1353 overwrites caller's arguments.
1354
1355 example:
1356
1357 int callee(int32, int64);
1358 int caller(int32 arg1, int32 arg2) {
1359   int64 local = arg2 * 2;
1360   return callee(arg2, (int64)local);
1361 }
1362
1363 [arg1]          [!arg2 no longer valid since we moved local onto it]
1364 [arg2]      ->  [(int64)
1365 [RETADDR]        local  ]
1366
1367 Moving arg1 onto the stack slot of callee function would overwrite
1368 arg2 of the caller.
1369
1370 Possible optimizations:
1371
1372  - Only push those arguments to the top of the stack that are actual
1373    parameters of the caller function and have no local value in the
1374    caller.
1375
1376    In the above example local does not need to be pushed onto the top
1377    of the stack as it is definitely not a caller's function
1378    parameter.
1379
1380  - Analyse the actual parameters of the callee to see which would
1381    overwrite a caller parameter which is used by the callee and only
1382    push them onto the top of the stack.
1383
1384    int callee (int32 arg1, int32 arg2);
1385    int caller (int32 arg1, int32 arg2) {
1386        return callee(arg1,arg2);
1387    }
1388
1389    Here we don't need to write any variables to the top of the stack
1390    since they don't overwrite each other.
1391
1392    int callee (int32 arg1, int32 arg2);
1393    int caller (int32 arg1, int32 arg2) {
1394        return callee(arg2,arg1);
1395    }
1396
1397    Here we need to push the arguments because they overwrite each
1398    other.
1399
1400
1401    Code for lowering directly onto callers arguments:
1402 +  SmallVector<std::pair<unsigned, SDOperand>, 8> RegsToPass;
1403 +  SmallVector<SDOperand, 8> MemOpChains;
1404 +
1405 +  SDOperand FramePtr;
1406 +  SDOperand PtrOff;
1407 +  SDOperand FIN;
1408 +  int FI = 0;
1409 +  // Walk the register/memloc assignments, inserting copies/loads.
1410 +  for (unsigned i = 0, e = ArgLocs.size(); i != e; ++i) {
1411 +    CCValAssign &VA = ArgLocs[i];
1412 +    SDOperand Arg = Op.getOperand(5+2*VA.getValNo());
1413 +
1414 +    ....
1415 +
1416 +    if (VA.isRegLoc()) {
1417 +      RegsToPass.push_back(std::make_pair(VA.getLocReg(), Arg));
1418 +    } else {
1419 +      assert(VA.isMemLoc());
1420 +      // create frame index
1421 +      int32_t Offset = VA.getLocMemOffset()+FPDiff;
1422 +      uint32_t OpSize = (MVT::getSizeInBits(VA.getLocVT())+7)/8;
1423 +      FI = MF.getFrameInfo()->CreateFixedObject(OpSize, Offset);
1424 +      FIN = DAG.getFrameIndex(FI, MVT::i32);
1425 +      // store relative to framepointer
1426 +      MemOpChains.push_back(DAG.getStore(Chain, Arg, FIN, NULL, 0));
1427 +    }
1428 +  }
1429 //===---------------------------------------------------------------------===//
1430
1431 main ()
1432 {
1433   int i = 0;
1434   unsigned long int z = 0;
1435
1436   do {
1437     z -= 0x00004000;
1438     i++;
1439     if (i > 0x00040000)
1440       abort ();
1441   } while (z > 0);
1442   exit (0);
1443 }
1444
1445 gcc compiles this to:
1446
1447 _main:
1448         subl    $28, %esp
1449         xorl    %eax, %eax
1450         jmp     L2
1451 L3:
1452         cmpl    $262144, %eax
1453         je      L10
1454 L2:
1455         addl    $1, %eax
1456         cmpl    $262145, %eax
1457         jne     L3
1458         call    L_abort$stub
1459 L10:
1460         movl    $0, (%esp)
1461         call    L_exit$stub
1462
1463 llvm:
1464
1465 _main:
1466         subl    $12, %esp
1467         movl    $1, %eax
1468         movl    $16384, %ecx
1469 LBB1_1: # bb
1470         cmpl    $262145, %eax
1471         jge     LBB1_4  # cond_true
1472 LBB1_2: # cond_next
1473         incl    %eax
1474         addl    $4294950912, %ecx
1475         cmpl    $16384, %ecx
1476         jne     LBB1_1  # bb
1477 LBB1_3: # bb11
1478         xorl    %eax, %eax
1479         addl    $12, %esp
1480         ret
1481 LBB1_4: # cond_true
1482         call    L_abort$stub
1483
1484 1. LSR should rewrite the first cmp with induction variable %ecx.
1485 2. DAG combiner should fold
1486         leal    1(%eax), %edx
1487         cmpl    $262145, %edx
1488    =>
1489         cmpl    $262144, %eax
1490
1491 //===---------------------------------------------------------------------===//
1492
1493 define i64 @test(double %X) {
1494         %Y = fptosi double %X to i64
1495         ret i64 %Y
1496 }
1497
1498 compiles to:
1499
1500 _test:
1501         subl    $20, %esp
1502         movsd   24(%esp), %xmm0
1503         movsd   %xmm0, 8(%esp)
1504         fldl    8(%esp)
1505         fisttpll        (%esp)
1506         movl    4(%esp), %edx
1507         movl    (%esp), %eax
1508         addl    $20, %esp
1509         #FP_REG_KILL
1510         ret
1511
1512 This should just fldl directly from the input stack slot.
1513
1514 //===---------------------------------------------------------------------===//
1515
1516 This code:
1517 int foo (int x) { return (x & 65535) | 255; }
1518
1519 Should compile into:
1520
1521 _foo:
1522         movzwl  4(%esp), %eax
1523         orb     $-1, %al           ;; 'orl 255' is also fine :)
1524         ret
1525
1526 instead of:
1527 _foo:
1528         movl    $255, %eax
1529         orl     4(%esp), %eax
1530         andl    $65535, %eax
1531         ret
1532
1533 //===---------------------------------------------------------------------===//
1534
1535 We're missing an obvious fold of a load into imul:
1536
1537 int test(long a, long b) { return a * b; }
1538
1539 LLVM produces:
1540 _test:
1541         movl    4(%esp), %ecx
1542         movl    8(%esp), %eax
1543         imull   %ecx, %eax
1544         ret
1545
1546 vs:
1547 _test:
1548         movl    8(%esp), %eax
1549         imull   4(%esp), %eax
1550         ret
1551
1552 //===---------------------------------------------------------------------===//
1553
1554 We can fold a store into "zeroing a reg".  Instead of:
1555
1556 xorl    %eax, %eax
1557 movl    %eax, 124(%esp)
1558
1559 we should get:
1560
1561 movl    $0, 124(%esp)
1562
1563 if the flags of the xor are dead.
1564
1565 //===---------------------------------------------------------------------===//
1566
1567 This testcase misses a read/modify/write opportunity (from PR1425):
1568
1569 void vertical_decompose97iH1(int *b0, int *b1, int *b2, int width){
1570     int i;
1571     for(i=0; i<width; i++)
1572         b1[i] += (1*(b0[i] + b2[i])+0)>>0;
1573 }
1574
1575 We compile it down to:
1576
1577 LBB1_2: # bb
1578         movl    (%esi,%edi,4), %ebx
1579         addl    (%ecx,%edi,4), %ebx
1580         addl    (%edx,%edi,4), %ebx
1581         movl    %ebx, (%ecx,%edi,4)
1582         incl    %edi
1583         cmpl    %eax, %edi
1584         jne     LBB1_2  # bb
1585
1586 the inner loop should add to the memory location (%ecx,%edi,4), saving
1587 a mov.  Something like:
1588
1589         movl    (%esi,%edi,4), %ebx
1590         addl    (%edx,%edi,4), %ebx
1591         addl    %ebx, (%ecx,%edi,4)
1592
1593 Here is another interesting example:
1594
1595 void vertical_compose97iH1(int *b0, int *b1, int *b2, int width){
1596     int i;
1597     for(i=0; i<width; i++)
1598         b1[i] -= (1*(b0[i] + b2[i])+0)>>0;
1599 }
1600
1601 We miss the r/m/w opportunity here by using 2 subs instead of an add+sub[mem]:
1602
1603 LBB9_2: # bb
1604         movl    (%ecx,%edi,4), %ebx
1605         subl    (%esi,%edi,4), %ebx
1606         subl    (%edx,%edi,4), %ebx
1607         movl    %ebx, (%ecx,%edi,4)
1608         incl    %edi
1609         cmpl    %eax, %edi
1610         jne     LBB9_2  # bb
1611
1612 Additionally, LSR should rewrite the exit condition of these loops to use
1613 a stride-4 IV, would would allow all the scales in the loop to go away.
1614 This would result in smaller code and more efficient microops.
1615
1616 //===---------------------------------------------------------------------===//