lib/Target/X86/README.txt

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