| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aggressive anti-dependency breaking is enabled by default for all PPC cores.
This provides a general speedup on the P7 and other platforms (among other
factors, the instruction group formation for the non-embedded PPC cores is done
during post-RA scheduling). In order to do this safely, the incompatibility
between uses of the MFOCRF instruction and anti-dependency breaking are
resolved by marking MFOCRF with hasExtraSrcRegAllocReq. As noted in the removed
FIXME, the problem was that MFOCRF's output is sensitive to the identify of the
source register, and always paired with a shift to undo this effect. Because
anti-dependency breaking is unaware of this hidden dependency of the shift
amount on the source register of the MFOCRF instruction, changing that register
must be inhibited.
Two test cases were adjusted: The SjLj test was made more insensitive to
register choices and scheduling; the saveCR test disabled anti-dependency
breaking because part of what it is testing is proper register reuse.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190587 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
There were a few places where kill flags were not being set correctly, and
where 32-bit instruction variants were being used with 64-bit registers. After
r178180, this code was being triggered causing llc to assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178220 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that the register scavenger can support multiple spill slots, and PEI can
use virtual-register-based scavenging for multiple simultaneous registers, we
can use a virtual register for the transfer register in the CR spilling code.
This should eliminate the last place (outside of the prologue/epilogue) where
we depend on the unconditional availability of the r0 register. We will soon be
able to allocate it (in a somewhat restricted sense) as a GPR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178060 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stack frame
For spills into a large stack frame, the FI-elimination code uses the register
scavenger to obtain a free GPR for use with an r+r-addressed load or store.
When there are no available GPRs, the scavenger gets one by using its spill
slot. Previously, we were not always allocating that spill slot and the RS
would assert when the spill slot was needed.
I don't currently have a small test that triggered the assert, but I've
created a small regression test that verifies that the spill slot is now
added when the stack frame is sufficiently large.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177140 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that only the register-scavenger version of the CR spilling code remains,
we no longer need the Darwin R2 hack. Darwin can use R0 as a spare register in
any case where the System V ABI uses it (R0 is special architecturally, and so
is reserved under all common ABIs).
A few test cases needed to be updated to reflect the register-allocation changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176868 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test).
2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147359 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
use the register scavenger because the scavenger can only scavenge one register and frame-index elimination may have already grabbed it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146318 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145963 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145819 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145817 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145699 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
haz. rec.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
stack frame, the prolog/epilog code was using the same
register for the copy of CR and the address of the save slot. Oops.
This is fixed here for Darwin, sort of, by reserving R2 for this case.
A better way would be to do the store before the decrement of SP,
which is safe on Darwin due to the red zone.
SVR4 probably has the same problem, but I don't know how to fix it;
there is no red zone and R2 is already used for something else.
I'm going to leave it to someone interested in that target.
Better still would be to rewrite the CR-saving code completely;
spilling each CR subregister individually is horrible code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8
|
