Rename TargetFrameInfo into TargetFrameLowering. Also, put couple of FIXMEs and fixes here and there.

llvm-svn: 123170

llvm-svn: 122994

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

  1. Allocate them in the entry block of the function to enable function-wide
     re-use. The instructions to create them should be re-materializable, so
     there shouldn't be additional cost compared to creating them local
     to the basic blocks where they are used.
  2. Collect all of the frame index references for the function and sort them
     by the local offset referenced. Iterate over the sorted list to
     allocate the virtual base registers. This enables creation of base
     registers optimized for positive-offset access of frame references.
     (Note: This may be appropriate to later be a target hook to do the
     sorting in a target appropriate manner. For now it's done here for
     simplicity.)

llvm-svn: 112609

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

relative offsets when there are offsets encoded in the instructions and
simplifies final allocation in PEI. rdar://8277890

llvm-svn: 111836

llvm-svn: 111673

llvm-svn: 111670

llvm-svn: 111646

llvm-svn: 111585

base registers were required. This will allow for slightly better packing
of the locals when alignment padding is necessary after callee saved registers.

llvm-svn: 111508

llvm-svn: 111453

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

llvm-svn: 111274

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

llvm-svn: 111206

mapping. Have the local block track its alignment requirement, and then
apply that when the block itself is allocated. Previously, offsets could
get adjusted in PEI to be different, relative to one another, than the
block allocation thought they would be, which defeats the point of doing
the allocation this way. Continuing rdar://8277890

llvm-svn: 111197

llvm-svn: 111164

experimental pass that allocates locals relative to one another before
register allocation and then assigns them to actual stack slots as a block
later in PEI. This will eventually allow targets with limited index offset
range to allocate additional base registers (not just FP and SP) to
more efficiently reference locals, as well as handle situations where
locals cannot be referenced via SP or FP at all (dynamic stack realignment
together with variable sized objects, for example). It's currently
incomplete and almost certainly buggy. Work in progress.

Disabled by default and gated via the -enable-local-stack-alloc command
line option.

rdar://8277890

llvm-svn: 111059