| cd81d94322a39503e4a3e87b6ee03d4fcb3465fb |
|
21-Jul-2014 |
Stephen Hines <srhines@google.com> |
Update LLVM for rebase to r212749.
Includes a cherry-pick of:
r212948 - fixes a small issue with atomic calls
Change-Id: Ib97bd980b59f18142a69506400911a6009d9df18
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| dce4a407a24b04eebc6a376f8e62b41aaa7b071f |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update LLVM for 3.5 rebase (r209712).
Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 36b56886974eae4f9c5ebc96befd3e7bfe5de338 |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Update to LLVM 3.5a.
Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 6af35e95765e2d577919714dfbdac3ebf84cac78 |
|
20-Aug-2013 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188741 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 9bb6c81683393363ed1ff8c66397f2d944c0966b |
|
16-Aug-2013 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188573 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| aad2a72c285a48e34d89ba69d24eb624f2b09b0e |
|
18-Jul-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC: Support dynamic allocas with large alignment
Support for dynamic stack alignments in the PPC backend has been unfinished, in
part because it depends on dynamic stack realignment (which I only just
recently implemented fully). Now we can also support dynamic allocas with
higher than the default target stack alignment (16 bytes).
In order to round-up the requested size to the maximum requested alignment, we
need an additional register to hold the rounded-up size. We're already using one
scavenged register to hold the previous stack-pointer value (which needs to be
stored with the signal-safe stdux update), and so when we have dynamic allocas
and a large alignment, we allocate two emergency spill slots for the scavenger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186562 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 0541722de4beb2e53058dbf4ed1ebf0d96ddd6cb |
|
18-Jul-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC: Add base-pointer support to builtin setjmp/longjmp
First, this changes the base-pointer implementation to remove an unnecessary
complication (and one that is incompatible with how builtin SjLj is
implemented): instead of using r31 as the base pointer when it is not needed as
a frame pointer, now the base pointer will always be r30 when needed.
Second, we introduce another pseudo register, BP, which is used just like the FP
pseudo register to refer to the base register before we know for certain what
register it will be.
Third, we now save BP into the jmp_buf, and restore r30 from that slot in
longjmp. If the function that called setjmp did not use a base pointer, then
r30 will be overwritten by the setjmp-calling-function's restore code. FP
restoration (which is restored into r31) works the same way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186545 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| fe47bf8fa07e12b70ff8b234fa1f6b97c8d2753d |
|
17-Jul-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC: Implement base pointer and stack realignment
This builds on some frame-lowering code that has existed since 2005 (r24224)
but was disabled in 2008 (r48188) because it needed base pointer support to
function correctly. This implementation follows the strategy suggested by Dale
Johannesen in r48188 where the following comment was added:
This does not currently work, because the delta between old and new stack
pointers is added to offsets that reference incoming parameters after the
prolog is generated, and the code that does that doesn't handle a variable
delta. You don't want to do that anyway; a better approach is to reserve
another register that retains to the incoming stack pointer, and reference
parameters relative to that.
And now we do exactly that. If we don't need a frame pointer, then we use r31
as a base pointer. If we do need a frame pointer, then we use r30 as a base
pointer. The base pointer retains the value of the stack pointer before it was
decremented in the prologue. We then use the base pointer to resolve all
negative frame indicies. The basic scheme follows that for base pointers in the
X86 backend.
We use a base pointer when we need to dynamically realign the incoming stack
pointer. This currently applies only to static objects (dynamic allocas with
large alignments, and base-pointer support in SjLj lowering will come in future
commits).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186478 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| a0ec3f9b7b826b9b40b80199923b664bad808cce |
|
14-Jul-2013 |
Craig Topper <craig.topper@gmail.com> |
Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186274 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 33efedc0481c4b0d9866ff526eb1161372b5919f |
|
03-Jul-2013 |
Ulrich Weigand <ulrich.weigand@de.ibm.com> |
[PowerPC] Use mtocrf when available
Just as with mfocrf, it is also preferable to use mtocrf instead of
mtcrf when only a single CR register is to be written.
Current code however always emits mtcrf. This probably does not matter
when using an external assembler, since the GNU assembler will in fact
automatically replace mtcrf with mtocrf when possible. It does create
inefficient code with the integrated assembler, however.
To fix this, this patch adds MTOCRF/MTOCRF8 instruction patterns and
uses those instead of MTCRF/MTCRF8 everything. Just as done in the
MFOCRF patch committed as 185556, these patterns will be converted
back to MTCRF if MTOCRF is not available on the machine.
As a side effect, this allows to modify the MTCRF pattern to accept
the full range of mask operands for the benefit of the asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185561 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 6a636a813f33b46b3271ec8517ee1936a0c92c9f |
|
29-Jun-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC: Ignore spill/restore requests for VRSAVE (except on Darwin)
This fixes PR16418, which reports that a function calling
__builtin_unwind_init() asserts. The cause is that this generates a
spill/restore for VRSAVE, and we support that only on Darwin (because VRSAVE is
only really used on Darwin).
The test case checks only that we don't crash. We can add correctness checks
once someone verifies what behavior the function is supposed to have.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185235 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 99cb622041a0839c7dfcf0263c5102a305a0fdb5 |
|
18-Jun-2013 |
Bill Wendling <isanbard@gmail.com> |
Use pointers to the MCAsmInfo and MCRegInfo.
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184175 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 6b67ffd68bb2e555b1b512a809f3c82c68f3debe |
|
16-May-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove addFrameMove.
Now that we have good testing, remove addFrameMove and create cfi
instructions directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182052 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 347a5079e18278803bc05b197d325b8580e95610 |
|
16-May-2013 |
Ulrich Weigand <ulrich.weigand@de.ibm.com> |
[PowerPC] Use true offset value in "memrix" machine operands
This is the second part of the change to always return "true"
offset values from getPreIndexedAddressParts, tackling the
case of "memrix" type operands.
This is about instructions like LD/STD that only have a 14-bit
field to encode immediate offsets, which are implicitly extended
by two zero bits by the machine, so that in effect we can access
16-bit offsets as long as they are a multiple of 4.
The PowerPC back end currently handles such instructions by
carrying the 14-bit value (as it will get encoded into the
actual machine instructions) in the machine operand fields
for such instructions. This means that those values are
in fact not the true offset, but rather the offset divided
by 4 (and then truncated to an unsigned 14-bit value).
Like in the case fixed in r182012, this makes common code
operations on such offset values not work as expected.
Furthermore, there doesn't really appear to be any strong
reason why we should encode machine operands this way.
This patch therefore changes the encoding of "memrix" type
machine operands to simply contain the "true" offset value
as a signed immediate value, while enforcing the rules that
it must fit in a 16-bit signed value and must also be a
multiple of 4.
This change must be made simultaneously in all places that
access machine operands of this type. However, just about
all those changes make the code simpler; in many cases we
can now just share the same code for memri and memrix
operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182032 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| ec7f4231cb7c26d5f52375617a9a73a1e79f3857 |
|
16-May-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Removed dead code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181975 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| ded53bf4dd499f213334400fa870d0c7896d1d0d |
|
14-May-2013 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
PPC32: Fix stack collision between FP and CR save areas.
The changes to CR spill handling missed a case for 32-bit PowerPC.
The code in PPCFrameLowering::processFunctionBeforeFrameFinalized()
checks whether CR spill has occurred using a flag in the function
info. This flag is only set by storeRegToStackSlot and
loadRegFromStackSlot. spillCalleeSavedRegisters does not call
storeRegToStackSlot, but instead produces MI directly. Thus we don't
see the CR is spilled when assigning frame offsets, and the CR spill
ends up colliding with some other location (generally the FP slot).
This patch sets the flag in spillCalleeSavedRegisters for PPC32 so
that the CR spill is properly detected and gets its own slot in the
stack frame.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181800 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| d84ccfaf50c7843f31ffc74a8a8e33f779453d6e |
|
11-May-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Change getFrameMoves to return a const reference.
To add a frame now there is a dedicated addFrameMove which also takes
care of constructing the move itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181657 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| fb6fe0aea2d1adde6d5e86f43797b5795ff2dc36 |
|
15-Apr-2013 |
Hal Finkel <hfinkel@anl.gov> |
Fix PPC64 CR spill location for callee-saved registers
This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition
registers, the spill location is specified relative to the stack pointer (SP +
8). However, this is not relative to the SP after the new stack frame is
established, but instead relative to the caller's stack pointer (it is stored
into the linkage area of the parent's stack frame).
So, like with the link register, we don't directly spill the CRs with other
callee-saved registers, but just mark them to be spilled during prologue
generation.
In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179500 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 63496f66c5b528a48f8da7714ee3f635f8aadd18 |
|
14-Apr-2013 |
Hal Finkel <hfinkel@anl.gov> |
Mark all PPC CR registers to be spilled as live-in and tag MFCR appropriately
Leaving MFCR has having unmodeled side effects is not enough to prevent
unwanted instruction reordering post-RA. We could probably apply a stronger
barrier attribute, but there is a better way: Add all (not just the first) CR
to be spilled as live-in to the entry block, and add all CRs to the MFCR
instruction as implicitly killed.
Unfortunately, I don't have a small test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179465 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| b99c995825a49f0da5af40ee1b61269deb8994b5 |
|
13-Apr-2013 |
Hal Finkel <hfinkel@anl.gov> |
Spill and restore PPC CR registers using the FP when we have one
For functions that need to spill CRs, and have dynamic stack allocations, the
value of the SP during the restore is not what it was during the save, and so
we need to use the FP in these cases (as for all of the other spills and
restores, but the CR restore has a special code path because its reserved slot,
like the link register, is specified directly relative to the adjusted SP).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179457 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| d957f957eee12cf26a7160e6015f0a7c2629904f |
|
28-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Cleanup PPC CR-spill kill flags and 32- vs. 64-bit instructions
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
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| aa6047d23d8ed55abd8545f5cbe82cd13cbd756a |
|
26-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC: Use HWEncoding and TRI->getEncodingValue
As pointed out by Jakob, we don't need to maintain a separate
register-numbering table. Instead we should let TableGen generate the table for
us from the information (already present) in PPCRegisterInfo.td.
TRI->getEncodingValue is now used to access register-encoding values.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178067 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 01f99d29c3010f2891e5edb78182216214017063 |
|
26-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Use multiple virtual registers in PPC CR spilling
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
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 3f2c047f32c9b488d9c49bb2dc87b979530dab3f |
|
23-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Note in PPCFunctionInfo VRSAVE spills
In preparation for using the new register scavenger capability for providing
more than one register simultaneously, specifically note functions that have
spilled VRSAVE (currently, this can happen only in functions that use the
setjmp intrinsic). As with CR spilling, such functions will need to provide two
emergency spill slots to the scavenger.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| dc3beb90178fc316f63790812b22201884eaa017 |
|
23-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Allow the register scavenger to spill multiple registers
This patch lets the register scavenger make use of multiple spill slots in
order to guarantee that it will be able to provide multiple registers
simultaneously.
To support this, the RS's API has changed slightly: setScavengingFrameIndex /
getScavengingFrameIndex have been replaced by addScavengingFrameIndex /
isScavengingFrameIndex / getScavengingFrameIndices.
In forthcoming commits, the PowerPC backend will use this capability in order
to implement the spilling of condition registers, and some special-purpose
registers, without relying on r0 being reserved. In some cases, spilling these
registers requires two GPRs: one for addressing and one to hold the value being
transferred.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177774 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| e9cc0a09ae38c87b1b26a44f5e32222ede4f84e6 |
|
21-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Correct PPC FRAMEADDR lowering using a pseudo-register
The old code used to lower FRAMEADDR tried to replicate the logic in the real
frame-lowering code that determines whether or not the frame pointer (r31) will
be used. When it seemed as through the frame pointer would not be used, the
stack pointer (r1) was used instead. Unfortunately, because the stack size is
not yet known, this does not work. Instead, this change introduces new
always-reserved pseudo-registers (FP and FP8) that are replaced during prologue
insertion with the real frame-pointer register (either r1 or r31).
It is important that this intrinsic always return a valid frame address because
it is used by Clang to store the frame address as part of code generation for
__builtin_setjmp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177653 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 324972904353594ad4a0cdfc79370f85e9fb9c8f |
|
17-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Improve PPC VR (Altivec) register spilling
This change cleans up two issues with Altivec register spilling:
1. The spilling code was inefficient (using two instructions, and add and a
load, when just one would do)
2. The code assumed that r0 would always be available (true for now, but this
will change)
The new code handles VR spilling just like GPR spills but forced into r+r mode.
As a result, when any VR spills are present, we must now always allocate the
register-scavenger spill slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177231 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 0cfb42adb5072fb19a01dba3ea58a33fd5927947 |
|
15-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Allocate the RS spill slot for any PPC function with spills and a large 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
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 3080d23fde4981835d8a7faf46c152441fadb11f |
|
14-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Provide the register scavenger to processFunctionBeforeFrameFinalized
Add the current PEI register scavenger as a parameter to the
processFunctionBeforeFrameFinalized callback.
This change is necessary in order to allow the PowerPC target code to
set the register scavenger frame index after the save-area offset
adjustments performed by processFunctionBeforeFrameFinalized. Only
after these adjustments have been made is it possible to estimate
the size of the stack frame.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177108 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 100a94bc93dcf9af99eba169599ce950faf0df7e |
|
14-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Not all PPC functions with a frame pointer need a RS spill slot
We used to add a spill slot for the register scavenger whenever the function
has a frame pointer. This is unnecessarily conservative: We may need the spill
slot for dynamic stack allocations, and functions with dynamic stack
allocations always have a FP, but we might also have a FP for other reasons
(such as the user explicitly disabling frame-pointer elimination), and we don't
necessarily need a spill slot for those functions.
The structsinregs test needed adjustment because it disables FP elimination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177106 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 65396823305326bcb379e88a95ded318e1da875c |
|
26-Feb-2013 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
Fix PR15332 (patch by Florian Zeitz).
There's no need to generate a stack frame for PPC32 SVR4 when there are
no local variables assigned to the stack, i.e., when no red zone is needed.
(PPC64 supports a red zone, but PPC32 does not.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176124 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 4edd84da1b3f7fd73e96a13b6b7e183ad04ac7c4 |
|
24-Feb-2013 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
Fix PR14364.
This removes a const_cast hack from PPCRegisterInfo::hasReservedSpillSlot().
The proper place to save the frame index for the CR spill slot is in the
PPCFunctionInfo object, not the PPCRegisterInfo object.
No new test cases, as this just reimplements existing function. Existing
tests such as test/CodeGen/PowerPC/crsave.ll are sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175998 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 700ed80d3da5e98e05ceb90e9bfb66058581a6db |
|
21-Feb-2013 |
Eli Bendersky <eliben@google.com> |
Move the eliminateCallFramePseudoInstr method from TargetRegisterInfo
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.
There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.
The refactoring was OK'd by Anton Korobeynikov on llvmdev.
Note: this touches the target interfaces, so out-of-tree targets may
be affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175788 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 0a9d1d31e9b3239b1dc38a67d31810c4bb405d0a |
|
05-Feb-2013 |
Jakob Stoklund Olesen <stoklund@2pi.dk> |
Avoid using MRI::liveout_iterator for computing VRSAVEs.
The liveout lists are about to be removed from MRI, this is the only
place they were used after register allocation.
Get the live out V registers directly from the return instructions
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174399 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 0b8c9a80f20772c3793201ab5b251d3520b9cea3 |
|
02-Jan-2013 |
Chandler Carruth <chandlerc@gmail.com> |
Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 831737d329a727f53a1fb0572f7b7a8127208881 |
|
30-Dec-2012 |
Bill Wendling <isanbard@gmail.com> |
Remove the Function::getFnAttributes method in favor of using the AttributeSet
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171253 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 034b94b17006f51722886b0f2283fb6fb19aca1f |
|
19-Dec-2012 |
Bill Wendling <isanbard@gmail.com> |
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170502 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| d04a8d4b33ff316ca4cf961e06c9e312eff8e64f |
|
03-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Use the new script to sort the includes of every file under lib.
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| a5d0ab555384baa293b06686bec5a01fb9638ca3 |
|
10-Oct-2012 |
Bill Schmidt <wschmidt@linux.vnet.ibm.com> |
The PowerPC VRSAVE register has been somewhat of an odd beast since
the Altivec extensions were introduced. Its use is optional, and
allows the compiler to communicate to the operating system which
vector registers should be saved and restored during a context switch.
In practice, this information is ignored by the various operating
systems using the SVR4 ABI; the kernel saves and restores the entire
register state. Setting the VRSAVE register is no longer performed by
the AIX XL compilers, the IBM i compilers, or by GCC on Power Linux
systems. It seems best to avoid this logic within LLVM as well.
This patch avoids generating code to update and restore VRSAVE for the
PowerPC SVR4 ABIs (32- and 64-bit). The code remains in place for the
Darwin ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165656 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 6765834754cbb3cb0f15b4b15e98c5e73fa50066 |
|
09-Oct-2012 |
Bill Wendling <isanbard@gmail.com> |
Create enums for the different attributes.
We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165488 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 2c189061184925c6a8ecbb5a19e648b230a41c0e |
|
26-Sep-2012 |
Bill Wendling <isanbard@gmail.com> |
Remove the `hasFnAttr' method from Function.
The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164725 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 9d760ae5c6bc1d1482e2824efcf9cb11db1cc16f |
|
12-Sep-2012 |
Roman Divacky <rdivacky@freebsd.org> |
This patch corrects logic in PPCFrameLowering for save and restore of
nonvolatile condition register fields across calls under the SVR4 ABIs.
* With the 64-bit ABI, the save location is at a fixed offset of 8 from
the stack pointer. The frame pointer cannot be used to access this
portion of the stack frame since the distance from the frame pointer may
change with alloca calls.
* With the 32-bit ABI, the save location is just below the general
register save area, and is accessed via the frame pointer like the rest
of the save areas. This is an optional slot, so it must only be created
if any of CR2, CR3, and CR4 were modified.
* For both ABIs, save/restore logic is generated only if one of the
nonvolatile CR fields were modified.
I also took this opportunity to clean up an extra FIXME in
PPCFrameLowering.h. Save area offsets for 32-bit GPRs are meaningless
for the 64-bit ABI, so I removed them for correctness and efficiency.
Fixes PR13708 and partially also PR13623. It lets us enable exception handling
on PPC64.
Patch by William J. Schmidt!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163713 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| ac81cc3282750d724f824547bc519caec0a01bce |
|
19-Jun-2012 |
Hal Finkel <hfinkel@anl.gov> |
Add support for generating reg+reg preinc stores on PPC.
PPC will now generate STWUX and friends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| b8f2f29467b86a11e777e2ce071caf15ae6fcf75 |
|
19-May-2012 |
Hal Finkel <hfinkel@anl.gov> |
Add a FIXME about access to negative stack-pointer offsets on PPC32.
The current code will generate a prologue which starts with something like:
mflr 0
stw 31, -4(1)
stw 0, 4(1)
stwu 1, -16(1)
But under the PPC32 SVR4 ABI, access to negative offsets from R1 is not allowed.
This was pointed out by Peter Bergner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157133 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| c909950c384e8234a7b3c5a76b7f79e3f7012ceb |
|
20-Apr-2012 |
Craig Topper <craig.topper@gmail.com> |
Convert some uses of XXXRegisterClass to &XXXRegClass. No functional change since they are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155186 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| b78ca423844f19f4a838abb49b4b4fa7ae499707 |
|
11-Mar-2012 |
Craig Topper <craig.topper@gmail.com> |
Use uint16_t to store registers and opcode in static tables in the target specific backends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152537 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 31d157ae1ac2cd9c787dc3c1d28e64c682803844 |
|
18-Feb-2012 |
Jia Liu <proljc@gmail.com> |
Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150878 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 2e95afa04cd1c89de7e4abaeead66cd8e51ec929 |
|
30-Dec-2011 |
Hal Finkel <hfinkel@anl.gov> |
Cleanup stack/frame register define/kill states. This fixes two bugs:
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
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 5a96b3dad2f634c9081c8b2b6c2575441dc5a2bd |
|
07-Dec-2011 |
Evan Cheng <evan.cheng@apple.com> |
Add bundle aware API for querying instruction properties and switch the code
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146026 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 3fd0018af1b692cabfa5a002bf41f1e756aa9dde |
|
05-Dec-2011 |
Hal Finkel <hfinkel@anl.gov> |
enable PPC register scavenging by default (update tests and remove some FIXMEs)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145819 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 8a8d479214745c82ef00f08d4e4f1c173b5f9ce2 |
|
02-Dec-2011 |
Nick Lewycky <nicholas@mxc.ca> |
Move global variables in TargetMachine into new TargetOptions class. As an API
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.
One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145714 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 95c885d65a0da92f6661fd160d8ce13b30e3892c |
|
29-Oct-2011 |
Benjamin Kramer <benny.kra@googlemail.com> |
PPC: Disable moves for all CR subregisters.
Should fix assertion failures on ppc buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 966aeb5788c242cfaca35c56c0ddc0ff778d4376 |
|
25-Jul-2011 |
Evan Cheng <evan.cheng@apple.com> |
Refactor PPC target to separate MC routines from Target routines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135942 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 2d28617de2b0b731c08d1af9e830f31e14ac75b4 |
|
19-Jul-2011 |
Evan Cheng <evan.cheng@apple.com> |
Move getInitialFrameState from TargetFrameInfo to MCAsmInfo (suggestions for
better location welcome).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135438 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 6e032942cf58d1c41f88609a1cec74eb74940ecd |
|
30-May-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Use the dwarf->llvm mapping to print register names in the cfi
directives.
Fixes PR9826.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132317 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| fc2bb8c4448fa884d79e437cc2d2627a7d7740a8 |
|
25-May-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Replace the -unwind-tables option with a per function flag. This is more
LTO friendly as we can now correctly merge files compiled with or without
-fasynchronous-unwind-tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132033 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 4f28c1c71450c711e96aa283de53739d8b4504cd |
|
13-Jan-2011 |
Jakob Stoklund Olesen <stoklund@2pi.dk> |
Teach frame lowering to ignore debug values after the terminators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123399 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|
| 16c29b5f285f375be53dabaa73e3e91107485fe4 |
|
10-Jan-2011 |
Anton Korobeynikov <asl@math.spbu.ru> |
Rename TargetFrameInfo into TargetFrameLowering. Also, put couple of FIXMEs and fixes here and there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123170 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
|