MachineFunction::iterator instead of MachineBasicBlock* to avoid
dereferencing end iterators.

llvm-svn: 15373

FallThrough maybe == to MF.end().

llvm-svn: 15372

llvm-svn: 15368

llvm-svn: 15351

These side-effects seem to make a difference when using llc -march=sparcv9
in Release mode (i.e., with -DNDEBUG); when they are left out, lots of
instructions just get dropped on the floor, because they never end up
in the schedule.

llvm-svn: 15339

llvm-svn: 15334

http://llvm.cs.uiuc.edu/PR403 .

llvm-svn: 15333

http://llvm.cs.uiuc.edu/PR403 .

llvm-svn: 15331

never overridden by any target.

llvm-svn: 15308

llvm-svn: 15200

llvm-svn: 15196

aggressively coallesce live ranges even if they overlap.  Consider this LLVM
code for example:

int %test(int %X) {
        %Y = mul int %X, 1      ;; Codegens to Y = X
        %Z = add int %X, %Y
        ret int %Z
}

The mul is just there to get a copy into the code stream.  This produces
this machine code:

 (0x869e5a8, LLVM BB @0x869b9a0):
        %reg1024 = mov <fi#-2>, 1, %NOREG, 0    ;; "X"
        %reg1025 = mov %reg1024                 ;; "Y"  (subsumed by X)
        %reg1026 = add %reg1024, %reg1025
        %EAX = mov %reg1026
        ret

Note that the life times of reg1024 and reg1025 overlap, even though they
contain the same value.  This results in this machine code:

test:
        mov %EAX, DWORD PTR [%ESP + 4]
        mov %ECX, %EAX
        add %EAX, %ECX
        ret

Another, worse case involves loops and PHI nodes.  Consider this trivial loop:
testcase:

int %test2(int %X) {
entry:
        br label %Loop
Loop:
        %Y = phi int [%X, %entry], [%Z, %Loop]
        %Z = add int %Y, 1
        %cond = seteq int %Z, 100
        br bool %cond, label %Out, label %Loop
Out:
        ret int %Z
}

Because of interactions between the PHI elimination pass and the register
allocator, this got compiled to this code:

test2:
        mov %ECX, DWORD PTR [%ESP + 4]
.LBBtest2_1:
***     mov %EAX, %ECX
        inc %EAX
        cmp %EAX, 100
***     mov %ECX, %EAX
        jne .LBBtest2_1

        ret

Or on powerpc, this code:

_test2:
        mflr r0
        stw r0, 8(r1)
        stwu r1, -60(r1)
.LBB_test2_1:
        addi r2, r3, 1
        cmpwi cr0, r2, 100
***     or r3, r2, r2
        bne cr0, .LBB_test2_1

***     or r3, r2, r2
        lwz r0, 68(r1)
        mtlr r0
        addi r1, r1, 60
        blr 0



With this improvement in place, we now generate this code for these two
testcases, which is what we want:


test:
        mov %EAX, DWORD PTR [%ESP + 4]
        add %EAX, %EAX
        ret

test2:
        mov %EAX, DWORD PTR [%ESP + 4]
.LBBtest2_1:
        inc %EAX
        cmp %EAX, 100
        jne .LBBtest2_1 # Loop
        ret

Or on PPC:

_test2:
        mflr r0
        stw r0, 8(r1)
        stwu r1, -60(r1)
.LBB_test2_1:
        addi r3, r3, 1
        cmpwi cr0, r3, 100
        bne cr0, .LBB_test2_1

        lwz r0, 68(r1)
        mtlr r0
        addi r1, r1, 60
        blr 0


Static numbers for spill code loads/stores/reg-reg copies (smaller is better):

em3d:       before: 47/25/26         after: 44/22/24
164.gzip:   before: 433/245/310      after: 403/231/278
175.vpr:    before: 3721/2189/1581   after: 4144/2081/1423
176.gcc:    before: 26195/8866/9235  after: 25942/8082/8275
186.crafty: before: 4295/2587/3079   after: 4119/2519/2916
252.eon:    before: 12754/7585/5803  after: 12508/7425/5643
256.bzip2:  before: 463/226/315      after: 482:241/309


Runtime perf number samples on X86:

gzip: before: 41.09 after: 39.86
bzip2: runtime: before: 56.71s after: 57.07s
gcc: before: 6.16 after: 6.12
eon: before: 2.03s after: 2.00s
llvm-svn: 15194

llvm-svn: 15193

same as the PHI use.  This is not correct as the PHI use value is different
depending on which branch is taken.  This fixes espresso with aggressive
coallescing, and perhaps others.

llvm-svn: 15189

llvm-svn: 15188

llvm-svn: 15187

not used accidentally.

llvm-svn: 15172

LiveInterval>. This saves some space and removes the pointer
indirection caused by following the pointer.

llvm-svn: 15167

llvm-svn: 15157

us back to taking about 10.5s on gcc, instead of taking 15.6s!  The net result
is that my big patches have hand no significant effect on compile time or code
quality.  heh.

llvm-svn: 15156

ownership of the intervals.

llvm-svn: 15155

Interval.  This generalizes the isDefinedOnce mechanism that we used before
to help us coallesce ranges that overlap.  As part of this, every logical
range with a different value is assigned a different number in the interval.
For example, for code that looks like this:

0  X = ...
4  X += ...
  ...
N    = X

We now generate a live interval that contains two ranges: [2,6:0),[6,?:1)
reflecting the fact that there are two different values in the range at
different positions in the code.

Currently we are not using this information at all, so this just slows down
liveintervals.  In the future, this will change.

Note that this change also substantially refactors the joinIntervalsInMachineBB
method to merge the cases for virt-virt and phys-virt joining into a single
case, adds comments, and makes the code a bit easier to follow.

llvm-svn: 15154

make overlapsAliases take pointers instead of references
fix indentation

llvm-svn: 15153

* Fix comment typeo
* add dump() methods
* add a few new methods like getLiveRangeContaining, removeRange & joinable
  (which is currently the same as overlaps)
* Remove the unused operator==

Bigger change:

* In LiveInterval, instead of using a boolean isDefinedOnce to keep track of
  if there are > 1 definitions in a particular interval, keep a counter,
  NumValues to keep track of exactly how many there are.
* In LiveRange, add a new ValId element to indicate which of the numbered
  values each LiveRange belongs to.   We now no longer merge LiveRanges if
  they are of differing value ID's even if they are neighbors.

llvm-svn: 15152

 * Inline some functions
 * Eliminate some comparisons from the release build

This is good for another .3 on gcc.

llvm-svn: 15144

want to insert a new range into the middle of the vector, then delete ranges
one at a time next to the inserted one as they are merged.

Instead, if the inserted interval overlaps, just start merging.  The only time
we insert into the middle of the vector is when we don't overlap at all.  Also
delete blocks of live ranges if we overlap with many of them.

This patch speeds up joining by .7 seconds on a large testcase, but more
importantly gets all of the range adding code into addRangeFrom.

llvm-svn: 15141

comparisons, reducing linscan by another .1 seconds :)

llvm-svn: 15139

llvm-svn: 15138

llvm-svn: 15137

a very modest speedup of .3 seconds compiling 176.gcc (out of 20s).

llvm-svn: 15136

llvm-svn: 15135

will soon be renamed) into their own file.  The new file should not emit
DEBUG output or have other side effects.  The LiveInterval class also now
doesn't know whether its working on registers or some other thing.

In the future we will want to use the LiveInterval class and friends to do
stack packing.  In addition to a code simplification, this will allow us to
do it more easily.

llvm-svn: 15134

Use an explicit LiveRange class to represent ranges instead of an std::pair.
This is a minor cleanup, but is really intended to make a future patch simpler
and less invasive.

Alkis, could you please take a look at LiveInterval::liveAt?  I suspect that
you can add an operator<(unsigned) to LiveRange, allowing us to speed up the
upper_bound call by quite a bit (this would also apply to other callers of
upper/lower_bound).  I would do it myself, but I still don't understand that
crazy liveAt function, despite the comment. :)

Basically I would like to see this:
    LiveRange dummy(index, index+1);
    Ranges::const_iterator r = std::upper_bound(ranges.begin(),
                                                ranges.end(),
                                                dummy);

Turn into:
    Ranges::const_iterator r = std::upper_bound(ranges.begin(),
                                                ranges.end(),
                                                index);

llvm-svn: 15130

the live intervals for some registers.

llvm-svn: 15125

interfere.  Because these intervals have a single definition, and one of them
is a copy instruction, they are always safe to merge even if their lifetimes
interfere.  This slightly reduces the amount of spill code, for example on
252.eon, from:

 12837 spiller               - Number of loads added
  7604 spiller               - Number of stores added
  5842 spiller               - Number of register spills
 18155 liveintervals         - Number of identity moves eliminated after coalescing

to:

  12754 spiller               - Number of loads added
   7585 spiller               - Number of stores added
   5803 spiller               - Number of register spills
  18262 liveintervals         - Number of identity moves eliminated after coalescing

The much much bigger win would be to merge intervals with multiple definitions
(aka phi nodes) but this is not that day.

llvm-svn: 15124

llvm-svn: 15118

llvm-svn: 15115

llvm-svn: 15114

llvm-svn: 15111

llvm-svn: 15108