| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back-end support for the anyregcc calling convention
for use with patchpoints.
Since all registers are considered call-saved with anyregcc
(except for 0 and 1 which may still be clobbered by PLT stubs
and the like), this required adding support for saving and
restoring vector registers in prologue/epilogue code for the
first time. This is not used by any other calling convention.
llvm-svn: 326612
|
| |
|
|
|
|
| |
The Function can never be nullptr so we can return a reference.
llvm-svn: 320884
|
| |
|
|
|
|
|
|
|
|
| |
Headers/Implementation files should be named after the class they
declare/define.
Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"` in
favor of `class LiveIntarvals;`
llvm-svn: 320546
|
| |
|
|
|
|
|
|
| |
The 32 bit subreg indices of GR128 registers must also be checked for in
getRC32().
Review: Ulrich Weigand.
llvm-svn: 318652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The method getRegAllocationHints() is now of bool type instead of void. If
true is returned, regalloc (AllocationOrder) will *only* try to allocate the
hints, as opposed to merely trying them before non-hinted registers.
* TargetRegisterInfo::getRegAllocationHints() is implemented for SystemZ with
an increase in number of LOCRs.
In this case, it is desired to force the hints even though there is a slight
increase in spilling, because if a non-hinted register would be allocated,
the LOCRMux pseudo would have to be expanded with a jump sequence. The LOCR
(Load On Condition) SystemZ instruction must have both operands in either the
low or high part of the 64 bit register.
Reviewers: Quentin Colombet and Ulrich Weigand
https://reviews.llvm.org/D36795
llvm-svn: 317879
|
| |
|
|
|
|
|
|
|
|
|
| |
This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.
This fixes a link error with modular codegeneration builds - where a
header and its implementation are circularly dependent and so need to be
in the same library, not split between two like this.
llvm-svn: 317379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement shouldCoalesce() to help regalloc avoid running out of GR128
registers.
If a COPY involving a subreg of a GR128 is coalesced, the live range of the
GR128 virtual register will be extended. If this happens where there are
enough phys-reg clobbers present, regalloc will run out of registers (if
there is not a single GR128 allocatable register available).
This patch tries to allow coalescing only when it can prove that this will be
safe by checking the (local) interval in question.
Review: Ulrich Weigand, Quentin Colombet
https://reviews.llvm.org/D37899
https://bugs.llvm.org/show_bug.cgi?id=34610
llvm-svn: 314516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add the 16 access registers as LLVM registers. This allows removing
a lot of special cases in the assembler and disassembler where we
were handling access registers; this can all just use the generic
register code now.
Also add a bunch of instructions to operate on access registers,
for assembler/disassembler use only. No change in code generation
intended.
llvm-svn: 286283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|