the copyto/fromregs instead of making the PPCISD::CALL selection code create
them. This vastly simplifies the selection code, and moves the ABI handling
parts into one place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28346 91177308-0d34-0410-b5e6-96231b3b80d8
1. Rearrange code a bit so that the special case doesn't require indenting lots
of code.
2. Add comments describing PPC calling convention.
3. Only round up to 56-bytes of stack space for an outgoing call if the callee
is varargs. This saves a bit of stack space.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28342 91177308-0d34-0410-b5e6-96231b3b80d8
ISD::CALL node, then custom lower that. This means that we only have to handle
LEGAL call operands/results, not every possible type. This allows us to
simplify the call code, shrinking it by about 1/3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28339 91177308-0d34-0410-b5e6-96231b3b80d8
handling. This makes the lower argument code significantly simpler (we
only need to handle legal argument types).
Incidentally, this also implements support for vector argument registers,
so long as they are not on the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28331 91177308-0d34-0410-b5e6-96231b3b80d8
Nate, please verify that if InsertMask is 0, rlwimi shouldn't be used.
This fixes the crash and causes no PPC testsuite regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28243 91177308-0d34-0410-b5e6-96231b3b80d8
really a bad codegen bug that LLC happens to get lucky with. I must chat with
Nate for the proper fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28213 91177308-0d34-0410-b5e6-96231b3b80d8
still a couple missed optimizations, but we now generate all the possible
rlwimis for multiple inserts into the same bitfield. More regression tests
to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28156 91177308-0d34-0410-b5e6-96231b3b80d8
Loading and storing off R0 isn't what we wanted. Also, taking some CR's out of
CRRC seems to cause failures as well. Further investigation is required.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28097 91177308-0d34-0410-b5e6-96231b3b80d8
simplifies the MachineCodeEmitter interface just a little bit and makes
BasicBlocks work like constant pools and jump tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28082 91177308-0d34-0410-b5e6-96231b3b80d8
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28060 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
