the variable actually tracks.
N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103802 91177308-0d34-0410-b5e6-96231b3b80d8
Reverse-merging r103156 into '.':
U lib/Target/ARM/ARMInstrNEON.td
U lib/Target/ARM/ARMRegisterInfo.h
U lib/Target/ARM/ARMBaseRegisterInfo.cpp
U lib/Target/ARM/ARMBaseInstrInfo.cpp
U lib/Target/ARM/ARMRegisterInfo.td
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103159 91177308-0d34-0410-b5e6-96231b3b80d8
optimization for non-leaf functions. This will be hooked up to gcc's
-momit-leaf-frame-pointer option. rdar://7886181
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101984 91177308-0d34-0410-b5e6-96231b3b80d8
When a frame pointer is not otherwise required, and dynamic stack alignment
is necessary solely due to the spilling of a register with larger alignment
requirements than the default stack alignment, the frame pointer can be both
used as a general purpose register and a frame pointer. That goes poorly, for
obvious reasons. This patch brings back a bit of old logic for identifying
the use of such registers and conservatively reserves the frame pointer
during register allocation in such cases.
For now, implement for X86 only since it's 32-bit linux which is hitting this,
and we want a targeted fix for 2.7. As a follow-on, this will be expanded
to handle other targets, as theoretically the problem could arise elsewhere
as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100559 91177308-0d34-0410-b5e6-96231b3b80d8
is preparatory to having PEI's scavenged frame index value reuse logic
properly distinguish types of frame values (e.g., whether the value is
stack-pointer relative or frame-pointer relative).
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98086 91177308-0d34-0410-b5e6-96231b3b80d8
We cannot use a normal call here since it has extra unmodelled side
effects (it changes stack pointer). This should fix PR5292.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97884 91177308-0d34-0410-b5e6-96231b3b80d8
Extracting the low element of a vector is now done with EXTRACT_SUBREG,
and the zero-extension performed by load movss is now modeled with
SUBREG_TO_REG, and so on.
Register-to-register movss and movsd are no longer considered copies;
they are two-address instructions which insert a scalar into a vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97354 91177308-0d34-0410-b5e6-96231b3b80d8
created. This ensures it's updated at all time. It means targets which perform
dynamic stack alignment would know whether it is required and whether frame
pointer register cannot be made available register allocation.
This is a fix for rdar://7625239. Sorry, I can't create a reasonably sized test
case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96069 91177308-0d34-0410-b5e6-96231b3b80d8
function can support dynamic stack realignment. That's a much easier question
to answer at instruction selection stage than whether the function actually
will have dynamic alignment prologue. This allows the removal of the
stack alignment heuristic pass, and improves code quality for cases where
the heuristic would result in dynamic alignment code being generated when
it was not strictly necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93885 91177308-0d34-0410-b5e6-96231b3b80d8
FrameIndexes should be lowered, but the same way as
everything else (target dependent) rather than in a
special hacked way. The lowering needs to be done
for eventual purposes of Dwarf generation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93530 91177308-0d34-0410-b5e6-96231b3b80d8
slots. The AsmPrinter will use this information to determine whether to
print a spill/reload comment.
Remove default argument values. It's too easy to pass a wrong argument
value when multiple arguments have default values. Make everything
explicit to trap bugs early.
Update all targets to adhere to the new interfaces..
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87022 91177308-0d34-0410-b5e6-96231b3b80d8
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85042 91177308-0d34-0410-b5e6-96231b3b80d8
a virtual register to eliminate a frame index, it can return that register
and the constant stored there to PEI to track. When scavenging to allocate
for those registers, PEI then tracks the last-used register and value, and
if it is still available and matches the value for the next index, reuses
the existing value rather and removes the re-materialization instructions.
Fancier tracking and adjustment of scavenger allocations to keep more
values live for longer is possible, but not yet implemented and would likely
be better done via a different, less special-purpose, approach to the
problem.
eliminateFrameIndex() is modified so the target implementations can return
the registers they wish to be tracked for reuse.
ARM Thumb1 implements and utilizes the new mechanism. All other targets are
simply modified to adjust for the changed eliminateFrameIndex() prototype.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83467 91177308-0d34-0410-b5e6-96231b3b80d8
(i.e., there are no local variables and stuff), we still need to output FDE
information for the pushed registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80960 91177308-0d34-0410-b5e6-96231b3b80d8
what was there before. In "no FP mode", we weren't generating labels and unwind
table entries after each "push" instruction. While more than likely "okay", it's
not technically correct. The major thing was that the ordering of when to define
a new CFA register and at what offset wasn't correct. This would cause the
exception handling to fail in ways most miserable to users.
I also cleaned up some code a bit. There's one function which has a "return" at
the beginning, so it's never used. Should I just remove it? :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79139 91177308-0d34-0410-b5e6-96231b3b80d8
