| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Port rL265480, rL264754, rL265997 and rL266252 to SystemZ, in order to enable the Swift port on the architecture. SwiftSelf and SwiftError are assigned to R10 and R9, respectively, which are normally callee-saved registers. For more information, see:
RFC: Implementing the Swift calling convention in LLVM and Clang
https://groups.google.com/forum/#!topic/llvm-dev/epDd2w93kZ0
Reviewers: kbarton, manmanren, rjmccall, uweigand
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19414
llvm-svn: 267823
|
|
|
|
|
|
|
|
|
|
|
|
| |
On z13, if eliminateFrameIndex() chooses LE (and not LEY), immediately
transform that LE to LDE32 to avoid partial register dependencies.
LEY should be generally preferred for big offsets over an expansion
into LAY + LDE32.
Reviewed by Ulrich Weigand.
llvm-svn: 266060
|
|
|
|
|
|
|
|
|
|
|
| |
function.
This was the same as getFrameIndexReference, but without the FrameReg
output.
Differential Revision: http://reviews.llvm.org/D12042
llvm-svn: 245148
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The target frame lowering's concrete type is always known in RegisterInfo, yet it's only sometimes devirtualized through a static_cast. This change adds an auto-generated static function <Target>GenRegisterInfo::getFrameLowering(const MachineFunction &MF) which does this devirtualization, and uses this function in all targets which can.
This change was suggested by sunfish in D11070 for WebAssembly, I figure that I may as well improve the other targets while I'm here.
Subscribers: sunfish, ted, llvm-commits, jfb
Differential Revision: http://reviews.llvm.org/D11093
llvm-svn: 241921
|
|
|
|
|
|
|
| |
MachineFunction argument so that we can grab subtarget specific
features off of it.
llvm-svn: 231979
|
|
|
|
|
|
|
|
|
|
|
| |
shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lookups from
the MachineFunction easily.
Update the MIPS subtarget switching machinery to update this pointer
at the same time it runs.
llvm-svn: 214838
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
|
|
| |
Just a clean-up. No behavioral change intended.
llvm-svn: 212711
|
|
|
|
|
|
|
|
| |
SystemZRegisterInfo and replace it with the subtarget as that's
all they needed in the first place. Update all uses and calls
accordingly.
llvm-svn: 211877
|
|
|
|
|
|
|
|
|
|
|
|
| |
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...
llvm-svn: 206838
|
|
|
|
| |
llvm-svn: 205610
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 203106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds the basics necessary for allocating the upper words to
virtual registers (move, load and store). The move support is parameterised
in a way that makes it easy to handle zero extensions, but the associated
zero-extend patterns are added by a later patch.
The easiest way of testing this seemed to be add a new "h" register
constraint for high words. I don't expect the constraint to be useful
in real inline asms, but it should work, so I didn't try to hide it
behind an option.
llvm-svn: 191739
|
|
|
|
|
|
|
|
| |
I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.
llvm-svn: 191655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SystemZ wants normal register scavenging slots, as close to the stack or
frame pointer as possible. The only reason it was using custom code was
because PrologEpilogInserter assumed an x86-like layout, where the frame
pointer is at the opposite end of the frame from the stack pointer.
This meant that when frame pointer elimination was disabled,
the slots ended up being as close as possible to the incoming
stack pointer, which is the opposite of what we want on SystemZ.
This patch adds a new knob to say which layout is used and converts
SystemZ to use target-independent scavenging slots. It's one of the pieces
needed to support frame-to-frame MVCs, where two slots might be required.
The ABI requires us to allocate 160 bytes for calls, so one approach
would be to use that area as temporary spill space instead. It would need
some surgery to make sure that the slot isn't live across a call though.
I stuck to the "isFPCloseToIncomingSP - ..." style comment on the
"do what the surrounding code does" principle. The FP case is already
covered by several Systemz/frame-* tests, which fail without the
PrologueEpilogueInserter change, so no new ones are needed.
No behavioural change intended.
llvm-svn: 185696
|
|
|
|
|
|
|
|
| |
the internals of TargetMachine could change.
No functionality change intended.
llvm-svn: 183567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the actual lib/Target/SystemZ target files necessary to
implement the SystemZ target. Note that at this point, the target
cannot yet be built since the configure bits are missing. Those
will be provided shortly by a follow-on patch.
This version of the patch incorporates feedback from reviews by
Chris Lattner and Anton Korobeynikov. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181203
|
|
|
|
| |
llvm-svn: 142878
|
|
|
|
|
|
|
|
|
| |
to MCRegisterInfo. Also initialize the mapping at construction time.
This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.
llvm-svn: 135424
|
|
|
|
|
|
| |
registeration and creation code into XXXMCDesc libraries.
llvm-svn: 135184
|
|
|
|
| |
llvm-svn: 134030
|
|
|
|
| |
llvm-svn: 134027
|
|
|
|
|
|
| |
into XXXGenRegisterInfo.inc.
llvm-svn: 133922
|
|
|
|
|
|
|
|
|
|
|
|
| |
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
llvm-svn: 133782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this actually changes code generation, and someone who
understands this target better should check the changes.
- R12Q is now allocatable. I think it was omitted from the allocation
order by mistake since it isn't reserved. It as apparently used as a
GOT pointer sometimes, and it should probably be reserved if that is
the case.
- The GR64 registers are allocated in a different order now. The
register allocator will automatically put the CSRs last. There were
other changes to the order that may have been significant.
The test fix is because r0 and r1 swapped places in the allocation order.
llvm-svn: 133067
|
|
|
|
|
|
|
|
| |
directives.
Fixes PR9826.
llvm-svn: 132317
|
|
|
|
|
|
| |
cross-class joins.
llvm-svn: 130857
|
|
|
|
|
|
| |
and fixes here and there.
llvm-svn: 123170
|
|
|
|
| |
llvm-svn: 120229
|
|
|
|
| |
llvm-svn: 119904
|
|
|
|
| |
llvm-svn: 119740
|
|
|
|
|
|
| |
out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place
llvm-svn: 119097
|
|
|
|
|
|
| |
to try to re-use scavenged frame index reference registers. rdar://8277890
llvm-svn: 112241
|
|
|
|
| |
llvm-svn: 105322
|
|
|
|
|
|
|
|
| |
replace the check with the appropriate predicate. Modify the testcase to reflect
the correct code. (It should be saving callee-saved registers on the stack
allocated by the calling fuction.)
llvm-svn: 103829
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 103802
|
|
|
|
|
|
|
| |
optimization for non-leaf functions. This will be hooked up to gcc's
-momit-leaf-frame-pointer option. rdar://7886181
llvm-svn: 101984
|
|
|
|
|
|
|
| |
solution. The only reason these don't fire with gcc-4.2 is that gcc turns off
part of -Wsign-compare in C++ on accident.
llvm-svn: 100581
|
|
|
|
| |
llvm-svn: 100214
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 98086
|
|
|
|
| |
llvm-svn: 94612
|
|
|
|
|
|
| |
Patch by Howard Hinnant!
llvm-svn: 90365
|
|
|
|
|
|
| |
This also fixes a build error.
llvm-svn: 87027
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 83467
|
|
|
|
|
|
| |
icc (#177, partial). Patch by Erick Tryzelaar.
llvm-svn: 81106
|
|
|
|
| |
llvm-svn: 76059
|
|
|
|
| |
llvm-svn: 76049
|
|
|
|
| |
llvm-svn: 76029
|
|
|
|
| |
llvm-svn: 76013
|
|
|
|
| |
llvm-svn: 76008
|