llvm-svn: 28064

llvm-svn: 28063

just have the JIT malloc them.

llvm-svn: 28062

llvm-svn: 28061

byte format.  This doesn't work when using the code emitter in a cross target
environment.  Since the code emitter is only really used by the JIT, this
isn't a current problem, but if we ever start emitting .o files, it would be.

llvm-svn: 28060

code emission location into the base class, instead of being in the derived classes.

This change means that low-level methods like emitByte/emitWord now are no longer
virtual (yaay for speed), and we now have a framework to support growable code
segments.  This implements feature request #1 of PR469.

llvm-svn: 28059

don't step on R11 in the middle of a function when saving and restoring CRs

llvm-svn: 28058

llvm-svn: 28057

llvm-svn: 28056

llvm-svn: 28055

llvm-svn: 28054

llvm-svn: 28053

llvm-svn: 28052

useful for debugging.

llvm-svn: 28051

basic block labels, consolidating the code to do so in one place for each
target.

llvm-svn: 28050

prologs and epilogs, keep all the asm in one place, and remove use of
compiler builtin functions.

llvm-svn: 28049

Domagoj Babic!

llvm-svn: 28048

llvm-svn: 28047

llvm-svn: 28046

llvm-svn: 28045

llvm-svn: 28044

llvm-svn: 28043

llvm-svn: 28042

instructions in the virtregfolded map that were deleted.  Because they
were deleted, newly allocated instructions could end up at the same address,
magically finding themselves in the map.  The solution is to remove entries
from the map when we delete the instructions.

llvm-svn: 28041

instruction folded with spill code, make sure the remove the load from
the virt reg folded map.

llvm-svn: 28040

llvm-svn: 28039

one for each instruction.

llvm-svn: 28038

llvm-svn: 28037

llvm-svn: 28036

llvm-svn: 28035

up the schedule. This helps code that looks like this:

loads ...
computations (first set) ...
stores (first set) ...
loads
computations (seccond set) ...
stores (seccond set) ...

Without this change, the stores and computations are more likely to
interleave:

loads ...
loads ...
computations (first set) ...
computations (second set) ...
computations (first set) ...
stores (first set) ...
computations (second set) ...
stores (stores set) ...

This can increase the number of spills if we are unlucky.

llvm-svn: 28033

llvm-svn: 28032

llvm-svn: 28030

Remove temp. option -spiller-check-liveout, it didn't cause any failure nor performance regressions.

llvm-svn: 28029

llvm-svn: 28028

llvm-svn: 28027

llvm-svn: 28026

But this is incorrect if the spilled value live range extends beyond the
current BB.
It is currently controlled by a temporary option -spiller-check-liveout.

llvm-svn: 28024

llvm-svn: 28023

with some changes I have to the new CFE.

llvm-svn: 28022