1. Change several methods in the MachineCodeEmitter class to be pure virtual.
2. Suck emitConstantPool/initJumpTableInfo into startFunction, removing them
from the MachineCodeEmitter interface, and reducing the amount of target-
specific code.
3. Change the JITEmitter so that it allocates constantpools and jump tables
*right* next to the functions that they belong to, instead of in a separate
pool of memory. This makes all memory for a function be contiguous, and
means the JITEmitter only tracks one block of memory now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28065 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28059 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28041 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28033 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28024 91177308-0d34-0410-b5e6-96231b3b80d8
and is already available, instead of falling back to emitting a load, fall
back to emitting a reg-reg copy. This generates significantly better code
for some SSE testcases, as SSE has lots of two-address instructions and
none of them are read/modify/write. As one example, this change does:
pshufd %XMM5, XMMWORD PTR [%ESP + 84], 255
xorps %XMM2, %XMM5
cmpltps %XMM1, %XMM0
- movaps XMMWORD PTR [%ESP + 52], %XMM0
- movapd %XMM6, XMMWORD PTR [%ESP + 52]
+ movaps %XMM6, %XMM0
cmpltps %XMM6, XMMWORD PTR [%ESP + 68]
movapd XMMWORD PTR [%ESP + 52], %XMM6
movaps %XMM6, %XMM0
cmpltps %XMM6, XMMWORD PTR [%ESP + 36]
cmpltps %XMM3, %XMM0
- movaps XMMWORD PTR [%ESP + 20], %XMM0
- movapd %XMM7, XMMWORD PTR [%ESP + 20]
+ movaps %XMM7, %XMM0
cmpltps %XMM7, XMMWORD PTR [%ESP + 4]
movapd XMMWORD PTR [%ESP + 20], %XMM7
cmpltps %XMM4, %XMM0
... which is far better than a store followed by a load!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28001 91177308-0d34-0410-b5e6-96231b3b80d8
x86 and ppc for 100% dense switch statements when relocations are non-PIC.
This support will be extended and enhanced in the coming days to support
PIC, and less dense forms of jump tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27947 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-gcc4 boostrap. Whenever a node is deleted by the dag combiner, it
*must* be returned by the visit function, or the dag combiner will not
know that the node has been processed (and will, e.g., send it to the
target dag combine xforms).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27922 91177308-0d34-0410-b5e6-96231b3b80d8
DAG combiner can turn a VAND V, <-1, 0, -1, -1>, i.e. vector clear elements,
into a vector shuffle with a zero vector. It only does so when TLI tells it
the xform is profitable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27874 91177308-0d34-0410-b5e6-96231b3b80d8
