| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
may be called. If the entry block is empty, the insertion point iterator will be
the "end()" value. Calling ->getParent() on it (among others) causes problems.
Modify materializeFrameBaseRegister to take the machine basic block and insert
the frame base register at the beginning of that block. (It's very similar to
what the code does all ready. The only difference is that it will always insert
at the beginning of the entry block instead of after a previous materialization
of the frame base register. I doubt that that matters here.)
<rdar://problem/8782198>
llvm-svn: 122104
|
|
|
|
|
|
| |
update the opcode when necessary as well as the source register.
llvm-svn: 121346
|
|
|
|
| |
llvm-svn: 120229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
state. Previously Thumb2 would restore sp from fp like this:
mov sp, r7
sub, sp, #4
If an interrupt is taken after the 'mov' but before the 'sub', callee-saved
registers might be clobbered by the interrupt handler. Instead, try
restoring directly from sp:
add sp, #4
Or, if necessary (with VLA, etc.) use a scratch register to compute sp and
then restore it:
sub.w r4, r7, #8
mov sp, r7
rdar://8465407
llvm-svn: 119977
|
|
|
|
| |
llvm-svn: 119904
|
|
|
|
| |
llvm-svn: 119740
|
|
|
|
| |
llvm-svn: 119604
|
|
|
|
|
|
| |
out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place
llvm-svn: 119097
|
|
|
|
| |
llvm-svn: 118827
|
|
|
|
| |
llvm-svn: 118823
|
|
|
|
|
|
| |
assumptions about stack layout. Specifically, LR must be saved next to FP.
llvm-svn: 118026
|
|
|
|
|
|
|
|
| |
the LDR instructions have. This makes the literal/register forms of the
instructions explicit and allows us to assign scheduling itineraries
appropriately. rdar://8477752
llvm-svn: 117505
|
|
|
|
|
|
| |
rdar://8477752.
llvm-svn: 117419
|
|
|
|
|
|
|
|
| |
explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.
llvm-svn: 117409
|
|
|
|
| |
llvm-svn: 117387
|
|
|
|
| |
llvm-svn: 116883
|
|
|
|
|
|
| |
base register is available. rdar://8525298
llvm-svn: 116729
|
|
|
|
|
|
|
|
| |
offset for stack references. Make sure we take that into account when
deciding whether to reserver an emergency spill slot for the register
scavenger. rdar://8559625
llvm-svn: 116714
|
|
|
|
| |
llvm-svn: 116712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
between the high and low registers for prologue/epilogue code. This was
a Darwin-only thing that wasn't providing a realistic benefit anymore.
Combining the save areas simplifies the compiler code and results in better
ARM/Thumb2 codegen.
For example, previously we would generate code like:
push {r4, r5, r6, r7, lr}
add r7, sp, #12
stmdb sp!, {r8, r10, r11}
With this change, we combine the register saves and generate:
push {r4, r5, r6, r7, r8, r10, r11, lr}
add r7, sp, #12
rdar://8445635
llvm-svn: 114340
|
|
|
|
|
|
|
|
|
| |
functions in ARMBaseInfo.h so it can be used in the MC library as well.
For anything bigger than this, we may want a means to have a small support
library for shared helper functions like this. Cross that bridge when we
come to it.
llvm-svn: 114016
|
|
|
|
|
|
| |
merge the common cases.
llvm-svn: 114013
|
|
|
|
|
|
| |
Re-running some nightly testers w/ it enabled to verify.
llvm-svn: 113399
|
|
|
|
|
|
| |
pointer was intended. rdar://8401980
llvm-svn: 113394
|
|
|
|
|
|
|
| |
option to disable base pointer usage, pay attention to it when deciding
if we can realign (if no base pointer and VLAs, we can't).
llvm-svn: 113366
|
|
|
|
| |
llvm-svn: 113365
|
|
|
|
|
|
| |
related. (attempt deux, complete w/ test update this time)
llvm-svn: 113333
|
|
|
|
| |
llvm-svn: 113332
|
|
|
|
| |
llvm-svn: 113331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"For ARM stack frames that utilize variable sized objects and have either
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs."
r112986 fixed a latent bug exposed by the above.
llvm-svn: 112989
|
|
|
|
|
|
|
|
|
| |
alignment should be performed. Otherwise dynamic realignment may trigger
when the register allocator has already used the frame pointer as a general
purpose register. That is, we need to make sure that the list of reserved
registers doesn't change after register allocation.
llvm-svn: 112986
|
|
|
|
|
|
|
|
| |
either", it is breaking oggenc with Clang for ARMv6.
This reverts commit 8d6e29cfda270be483abf638850311670829ee65.
llvm-svn: 112962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs.
rdar://7352504
rdar://8374540
rdar://8355680
llvm-svn: 112883
|
|
|
|
| |
llvm-svn: 112852
|
|
|
|
|
|
|
| |
determining if they're likely to be in range of the SP when resolving
frame references.
llvm-svn: 112624
|
|
|
|
|
|
| |
the offset is legally encodable, not actually trying to do the encoding.
llvm-svn: 112622
|
|
|
|
|
|
| |
to try to re-use scavenged frame index reference registers. rdar://8277890
llvm-svn: 112241
|
|
|
|
| |
llvm-svn: 112228
|
|
|
|
|
|
|
|
| |
still having a significant effect. It shouldn't be now that the pre-RA
virtual base reg stuff is in. Assuming that's valididated by the nightly
testers, we can simplify a lot of the PEI frame index code.
llvm-svn: 112220
|
|
|
|
| |
llvm-svn: 112127
|
|
|
|
|
|
|
| |
When doing copy/paste/modify, it's apparently rather important to remember
the 'modify' bit...
llvm-svn: 112075
|
|
|
|
|
|
| |
access. rdar://8277890&7352504
llvm-svn: 111968
|
|
|
|
|
|
|
| |
For now it's still a command line option, but the interface to the generic
code doesn't need to know that.
llvm-svn: 111942
|
|
|
|
|
|
|
| |
Intended to help ease reproducing problems by increasing base register usage
after heuristics for only using the when needed are in place.
llvm-svn: 111930
|
|
|
|
| |
llvm-svn: 111585
|
|
|
|
|
|
| |
rdar://8277890
llvm-svn: 111533
|
|
|
|
|
|
|
|
|
| |
frame index reference to an object in the local block is seen, check if
it's near enough to any previously allocaated base register to re-use.
rdar://8277890
llvm-svn: 111443
|
|
|
|
|
|
|
|
|
|
| |
Nothing fancy, just ask the target if any currently available base reg
is in range for the instruction under consideration and use the first one
that is. Placeholder ARM implementation simply returns false for now.
ongoing saga of rdar://8277890
llvm-svn: 111374
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the local block. Resolve references to those indices to a new base register.
For simplification and testing purposes, a new virtual base register is
allocated for each frame index being resolved. The result is truly horrible,
but correct, code that's good for exercising the new code paths.
Next up is adding thumb1 support, which should be very simple. Following that
will be adding base register re-use and implementing a reasonable ARM
heuristic for when a virtual base register should be generated at all.
llvm-svn: 111315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether to allocate a virtual frame base register to resolve the frame
index reference in it. Implement a simple version for ARM to aid debugging.
In LocalStackSlotAllocation, scan the function for frame index references
to local frame indices and ask the target whether to allocate virtual
frame base registers for any it encounters. Purely infrastructural for
debug output. Next step is to actually allocate base registers, then add
intelligent re-use of them.
rdar://8277890
llvm-svn: 111262
|