| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
After instruction selection we perform some checks on each VReg just before
discarding the type information. These checks were assertions before, but that
breaks the fallback path so this patch moves the logic into the main flow and
reports a better error on failure.
llvm-svn: 286289
|
|
|
|
| |
llvm-svn: 285423
|
|
|
|
| |
llvm-svn: 283851
|
|
|
|
|
|
| |
This should fix the fallout of r283848.
llvm-svn: 283850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes MachineRegisterInfo to be initializes after parsing all
instructions. This is in preparation for upcoming commits that allow the
register class specification on the operand or deduce them from the
MCInstrDesc.
This commit removes the unused feature of having nonsequential register
numbers. This was confusing anyway as the vreg numbers would be
different after parsing when you had "holes" in your numbering.
This patch also introduces the concept of an incomplete virtual
register. An incomplete virtual register may be used during .mir parsing
to construct MachineOperands without knowing the exact register class
(or register bank) yet.
NFC except for some error messages.
Differential Revision: https://reviews.llvm.org/D22397
llvm-svn: 283848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current implementation of isConstantPhysReg() checks for defs of
physical registers to determine if they are constant. Some
architectures (e.g. AArch64 XZR/WZR) have registers that are constant
and may be used as destinations to indicate the generated value is
discarded, preventing isConstantPhysReg() from returning true. This
change adds a TargetRegisterInfo hook that overrides the no defs check
for cases such as this.
Reviewers: MatzeB, qcolombet, t.p.northover, jmolloy
Subscribers: junbuml, aemerson, mcrosier, rengolin
Differential Revision: https://reviews.llvm.org/D24570
llvm-svn: 282543
|
|
|
|
|
|
|
|
| |
It was only really there as a sentinel when instructions had to have precisely
one type. Now that registers are typed, each register really has to have a type
that is sized.
llvm-svn: 281599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some generic instructions have multiple types. While in theory these always be
discovered by inspecting the single definition of each generic vreg, in
practice those definitions won't always be local and traipsing through a big
function to find them will not be fun.
So this changes MIRPrinter to print out the type of uses as well as defs, if
they're known to be different or not known to be the same.
On the parsing side, we're a little more flexible: provided each register is
given a type in at least one place it's mentioned (and all types are
consistent) we accept the MIR. This doesn't introduce ambiguity but makes
writing tests manually a bit less painful.
llvm-svn: 281204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want each register to have a canonical type, which means the best place to
store this is in MachineRegisterInfo rather than on every MachineInstr that
happens to use or define that register.
Most changes following from this are pretty simple (you need an MRI anyway if
you're going to be doing any transformations, so just check the type there).
But legalization doesn't really want to check redundant operands (when, for
example, a G_ADD only ever has one type) so I've made use of MCInstrDesc's
operand type field to encode these constraints and limit legalization's work.
As an added bonus, more validation is possible, both in MachineVerifier and
MachineIRBuilder (coming soon).
llvm-svn: 281035
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
print/parser it
tracksSubRegLiveness only depends on the Subtarget and a cl::opt, there
is not need to change it or save/parse it in a .mir file.
Make the field const and move the initialization LiveIntervalAnalysis to the
MachineRegisterInfo constructor. Also cleanup some code and fix some
instances which better use MachineRegisterInfo::subRegLivenessEnabled() instead
of TargetSubtargetInfo::enableSubRegLiveness().
llvm-svn: 279676
|
|
|
|
|
|
|
|
| |
And implement it for AArch64, supporting x/w ADD/OR.
Differential Revision: https://reviews.llvm.org/D22373
llvm-svn: 276875
|
|
|
|
|
|
|
|
|
|
| |
Also verify that we never try to set the size of a vreg associated
to a register class.
Report an error when we encounter that in MIR. Fix a testcase that
hit that error and had a size for no reason.
llvm-svn: 276012
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21395
Patch by Vivek Pandya.
PR28144
llvm-svn: 275087
|
|
|
|
|
|
|
|
|
|
| |
Use the MachineFunctionProperty mechanism to indicate whether the
liveness info is accurate instead of a bool flag on MRI.
Keeps the MRI accessor function for convenience. NFC
Differential Revision: http://reviews.llvm.org/D18767
llvm-svn: 266020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A virtual register may have either a register bank or a register class.
This is represented by a PointerUnion between the related classes.
Typically, a virtual register went through the following states
regarding register class and register bank:
1. Creation: None is set. Virtual registers are fully generic.
2. Register bank assignment: Register bank is set. Virtual registers
live into a register bank, but we do not know the constraints they need
to fulfil.
3. Instruction selection: Register class is set. Virtual registers are
bound by encoding constraints.
To map these states to GlobalISel, the IRTranslator implements #1,
RegBankSelect #2, and Select #3.
llvm-svn: 265696
|
|
|
|
|
|
|
|
|
| |
Use the MachineFunctionProperty mechanism to indicate whether a MachineFunction
is in SSA form instead of a custom method on MachineRegisterInfo. NFC
Differential Revision: http://reviews.llvm.org/D18574
llvm-svn: 265318
|
|
|
|
|
|
|
|
| |
posteriori.
This is required for mir testing.
llvm-svn: 262861
|
|
|
|
|
|
|
| |
One additional pointer is not a big deal size-wise and it makes
the code much nicer!
llvm-svn: 262856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now, generic virtual registers will not have a register class. We may want
to change that. For instance, if we want to use all the methods from
TargetRegisterInfo with generic virtual registers, we need to either have some
sort of generic register classes that do what we want, or teach those methods
how to deal with nullptr register class.
Although the latter seems easy enough to do, we may still want to differenciate
generic register classes from nullptr to catch cases where nullptr gets
introduced by a bug of some sort.
Anyway, I will file a PR to keep track of that.
llvm-svn: 260474
|
|
|
|
| |
llvm-svn: 260468
|
|
|
|
|
|
|
|
|
| |
vector.resize() is significantly slower than memset in many STLs
and the cost of initializing these vectors is significant on targets
with many registers. Since we don't need the overhead of a vector,
use a simple unique_ptr instead.
llvm-svn: 254526
|
|
|
|
|
|
| |
Patch by Richard.
llvm-svn: 251213
|
|
|
|
|
|
| |
apropriate; NFC
llvm-svn: 248623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method checks whether a physical regiser or any of its aliases are
used in the function.
Using this function in SIRegisterInfo::findUnusedReg() should also fix
this reported failure:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150803/292143.html
http://reviews.llvm.org/rL242173#inline-533
The report doesn't come with a testcase and I don't know enough about
AMDGPU to create one myself.
llvm-svn: 245329
|
|
|
|
|
|
|
|
|
| |
This commit zeroes out the virtual register references in the machine
function's liveins in the class 'MachineRegisterInfo' when the virtual
register definitions are cleared.
Reviewers: Matthias Braun
llvm-svn: 243290
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a detailed def/use lists for every physical register in
MachineRegisterInfo anyway, so there is little use in maintaining an
additional bitset of which ones are used.
Removing it frees us from extra book keeping. This simplifies
VirtRegMap.
Differential Revision: http://reviews.llvm.org/D10911
llvm-svn: 242173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes TargetFrameLowering::processFunctionBeforeCalleeSavedScan():
- Rename the function to determineCalleeSaves()
- Pass a bitset of callee saved registers by reference, thus avoiding
the function-global PhysRegUsed bitset in MachineRegisterInfo.
- Without PhysRegUsed the implementation is fine tuned to not save
physcial registers which are only read but never modified.
Related to rdar://21539507
Differential Revision: http://reviews.llvm.org/D10909
llvm-svn: 242165
|
|
|
|
|
|
|
| |
MachineFunction argument so that it can look up the subtarget
rather than using a cached one in some Targets.
llvm-svn: 231888
|
|
|
|
|
|
|
| |
subtarget and so doesn't need the TargetMachine or to access via
getSubtargetImpl. Update all callers.
llvm-svn: 227160
|
|
|
|
|
|
|
|
| |
Add in definedness checks for shift operators, null checks when
pointers are assumed by the code to be non-null, and explicit
unreachables.
llvm-svn: 224255
|
|
|
|
| |
llvm-svn: 223884
|
|
|
|
|
|
| |
This code adds the required data structures. Algorithms to compute it follow.
llvm-svn: 223877
|
|
|
|
| |
llvm-svn: 216355
|
|
|
|
|
|
|
|
| |
was created for rather than the TargetMachine since we only
needed the TM for the subtarget and we can get that from the
MF.
llvm-svn: 215432
|
|
|
|
|
|
|
|
| |
to use register units instead of registers.
reviewed by Jakob Stoklund Olesen.
llvm-svn: 214798
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206142
|
|
|
|
|
|
| |
the MachineRegisterInfo iterators are compatible with it.
llvm-svn: 204075
|
|
|
|
|
|
|
|
|
|
| |
operator* on the by-operand iterators to return a MachineOperand& rather than
a MachineInstr&. At this point they almost behave like normal iterators!
Again, this requires making some existing loops more verbose, but should pave
the way for the big range-based for-loop cleanups in the future.
llvm-svn: 203865
|
|
|
|
|
|
|
| |
This patch fixes the bug in peephole optimization that folds a load which defines one vreg into the one and only use of that vreg. With debug info, a DBG_VALUE that referenced the vreg considered to be a use, preventing the optimization. The fix is to ignore DBG_VALUE's during the optimization, and undef a DBG_VALUE that references a vreg that gets removed.
Patch by Trevor Smigiel!
llvm-svn: 203829
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The greedy register allocator tries to split a live-range around each
instruction where it is used or defined to relax the constraints on the entire
live-range (this is a last chance split before falling back to spill).
The goal is to have a big live-range that is unconstrained (i.e., that can use
the largest legal register class) and several small local live-range that carry
the constraints implied by each instruction.
E.g.,
Let csti be the constraints on operation i.
V1=
op1 V1(cst1)
op2 V1(cst2)
V1 live-range is constrained on the intersection of cst1 and cst2.
tryInstructionSplit relaxes those constraints by aggressively splitting each
def/use point:
V1=
V2 = V1
V3 = V2
op1 V3(cst1)
V4 = V2
op2 V4(cst2)
Because of how the coalescer infrastructure works, each new variable (V3, V4)
that is alive at the same time as V1 (or its copy, here V2) interfere with V1.
Thus, we end up with an uncoalescable copy for each split point.
To make tryInstructionSplit less aggressive, we check if the split point
actually relaxes the constraints on the whole live-range. If it does not, we do
not insert it.
Indeed, it will not help the global allocation problem:
- V1 will have the same constraints.
- V1 will have the same interference + possibly the newly added split variable
VS.
- VS will produce an uncoalesceable copy if alive at the same time as V1.
<rdar://problem/15570057>
llvm-svn: 198369
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 195064
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
|
| |
Add a delegate class to MachineRegisterInfo with a single virtual
function, MRI_NoteNewVirtualRegister(). Update LiveRangeEdit to inherit
from this delegate class and override the definition of the callback
with an implementation that tracks the newly created virtual registers.
llvm-svn: 188435
|
|
|
|
| |
llvm-svn: 184121
|
|
|
|
|
|
|
| |
This checks the sanity of the register use lists in the MI intermediate
representation.
llvm-svn: 179895
|
|
|
|
|
|
| |
We have the same assertion in createVirtualRegister.
llvm-svn: 176959
|