| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This adds the actual MachineLegalizeHelper to do the work and a trivial pass
wrapper that legalizes all instructions in a MachineFunction. Currently the
only transformation supported is splitting up a vector G_ADD into one acting on
smaller vectors.
llvm-svn: 276461
|
|
|
|
| |
llvm-svn: 276433
|
|
|
|
|
|
| |
This commit adds a generic SUB opcode to global-isel.
llvm-svn: 276308
|
|
|
|
|
|
| |
Group arithmetic operations, bitwise operations, and branch operations.
llvm-svn: 276305
|
|
|
|
|
|
| |
This commit adds a generic AND opcode to global-isel.
llvm-svn: 276297
|
|
|
|
|
|
|
| |
This adds an (incomplete, inefficient) framework for deciding what to do with
some operation on a given type.
llvm-svn: 276184
|
|
|
|
|
|
|
|
| |
This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining context taken from the opcode
(e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math).
llvm-svn: 276158
|
|
|
|
| |
llvm-svn: 276011
|
|
|
|
| |
llvm-svn: 275423
|
|
|
|
|
|
|
|
|
|
| |
We can freeze the registers after the MachineFrameInfo has been configured (by
telling it about calls, inline asm, ...). This doesn't happen at all yet, but
will be part of IR translation.
Fixes -verify-machineinstrs assertion.
llvm-svn: 275221
|
|
|
|
|
|
| |
Now or instructions get translated into G_OR.
llvm-svn: 272433
|
|
|
|
|
|
|
|
| |
This method will be used for every binary operation.
NFC.
llvm-svn: 272431
|
|
|
|
|
|
| |
This improves the debuggability of the pass.
llvm-svn: 272210
|
|
|
|
|
|
|
|
| |
For complex rewrittings, which do not occur currently, the related
machine instruction may have been deleted in the process. Therefore, do
not try to print it after the mapping is applied.
llvm-svn: 272209
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computation of the end of range.
Refactor the code so that we do not compute in two different places the
end iterator for the range of new virtual registers for a given operand.
Although this refactoring was intended as NFC, this is not the case
because it actually fixes a bug where we were returning a range off by 1
(too long). Right now, this could not result in an actual bug because we
were accessing this range via the BreakDown size of the related operand.
llvm-svn: 272208
|
|
|
|
|
|
| |
Improve debuggability of the OperandsMapper helper class.
llvm-svn: 272207
|
|
|
|
| |
llvm-svn: 272177
|
|
|
|
|
|
|
|
|
|
|
| |
When repairing with a copy, instead of accounting for the cost of that
copy and actually inserting it, we may be able to use an alternative
source for the register to repair and just use it.
Make sure this is documented, so that we consider that opportunity at
some point.
llvm-svn: 272176
|
|
|
|
|
|
|
| |
The RegBankSelect pass can now rely on the target to do the remapping of
the instructions.
llvm-svn: 272169
|
|
|
|
|
|
|
|
|
| |
Now, the target will be able to provide its how implementation to remap
an instruction. This open the way to crazier optimizations, but to
beginning with, we will be able to handle something else than the
default mapping.
llvm-svn: 272165
|
|
|
|
|
|
|
|
|
| |
Now that we have an entity that hold the remap information the
rewritting should be easier to do.
No functional changes.
llvm-svn: 272164
|
|
|
|
|
|
|
| |
The repairing code has no reason to change the source or destination of
the registers.
llvm-svn: 272163
|
|
|
|
|
|
|
| |
This helper class is used to encapsulate the necessary information
to remap an instruction.
llvm-svn: 272161
|
|
|
|
|
|
|
|
|
|
| |
When the command line option is set, it overrides any thing that the
target may have set. The rationale is that we get what we asked for.
Options are respectively regbankselect-fast and regbankselect-greedy for
fast and greedy mode.
llvm-svn: 272158
|
|
|
|
|
|
|
|
|
|
|
| |
repairing.
Copies are easy because we repair only when there is a mismatch. For
non-copy repairing, i.e., cases that involves breaking down or gathering
up the value, one of the operand may not have a register bank yet. Thus,
derivate a cost from that, requires more work.
llvm-svn: 272157
|
|
|
|
|
|
|
| |
The cost of a copy may be different based on how many bits we have to
copy around. E.g., a 8-bit copy may be different than a 32-bit copy.
llvm-svn: 272084
|
|
|
|
|
|
| |
This will allow code reuse in the coming commits.
llvm-svn: 272083
|
|
|
|
|
|
|
| |
Prior to this patch, we were using 1 for all the repairing costs.
Now, we use the information from the target to get this information.
llvm-svn: 270304
|
|
|
|
|
|
|
|
|
| |
The Fast mode takes the first mapping, the greedy mode loops over all
the possible mapping for an instruction and choose the cheaper one.
Test case will come with target specific code, since we currently do not
have instructions that have several mappings.
llvm-svn: 270249
|
|
|
|
|
|
| |
This is now encapsulated in the RepairingPlacement class.
llvm-svn: 270247
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computeMapping.
Computing the cost of a mapping takes some time.
Since in Fast mode, the cost is irrelevant, just spare some cycles by not
computing it.
In Greedy mode, we need to choose the best cost, that means that when
the local cost gets more expensive than the best cost, we can stop
computing the repairing and cost for the current mapping.
llvm-svn: 270245
|
|
|
|
|
|
|
|
|
| |
more precise cost in Greedy mode.
In Fast mode the cost is irrelevant so do not bother requiring that
those passes get scheduled.
llvm-svn: 270244
|
|
|
|
| |
llvm-svn: 270242
|
|
|
|
|
|
| |
The mode should be choose by the target when instantiating the pass.
llvm-svn: 270235
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous choice of the insertion points for repairing was
straightfoward but may introduce some basic block or edge splitting. In
some situation this is something we can avoid.
For instance, when repairing a phi argument, instead of placing the
repairing on the related incoming edge, we may move it to the previous
block, before the terminators. This is only possible when the argument
is not defined by one of the terminator.
llvm-svn: 270232
|
|
|
|
|
|
|
|
|
|
|
| |
an instruction.
Use the previously introduced RepairingPlacement class to split the code
computing the repairing placement from the code doing the actual
placement. That way, we will be able to consider different placement and
then, only apply the best one.
llvm-svn: 270168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When assigning the register banks we may have to insert repairing code
to move already assigned values accross register banks.
Introduce a few helper classes to keep track of what is involved in the
repairing of an operand:
- InsertPoint and its derived classes record the positions, in the CFG,
where repairing has to be inserted.
- RepairingPlacement holds all the insert points for the repairing of an
operand plus the kind of action that is required to do the repairing.
This is going to be used to keep track of how the repairing should be
done, while comparing different solutions for an instruction. Indeed, we
will need the repairing placement to capture the cost of a solution and
we do not want to compute it a second time when we do the actual
repairing.
llvm-svn: 270167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register bank twice.
Prior to this change, we were checking if the assignment for the current
machine operand was matching, then we would check if the mismatch
requires to insert repair code.
We actually already have this information from the first check, so just
pass it along.
NFCI.
llvm-svn: 270166
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This helper class will be used to represent the cost of mapping an
instruction to a specific register bank.
The particularity of these costs is that they are mostly local, thus the
frequency of the basic block is irrelevant. However, for few
instructions (e.g., phis and terminators), the cost may be non-local and
then, we need to account for the frequency of the involved basic blocks.
This will be used by the greedy mode I am working on.
llvm-svn: 270163
|
|
|
|
| |
llvm-svn: 267128
|
|
|
|
| |
llvm-svn: 267077
|
|
|
|
| |
llvm-svn: 267073
|
|
|
|
|
|
|
| |
Return bool instead of void so that it is natural to put the calls into
asserts.
llvm-svn: 267033
|
|
|
|
|
|
|
|
|
| |
Instead of holding a mask, hold two value: the start index and the
length of the mapping. This is a more compact representation, although
less powerful. That being said, arbitrary masks would not have worked
for the generic so do not allow them in the first place.
llvm-svn: 267025
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: qcolombet
Subscribers: joker.eph, llvm-commits, vkalintiris
Differential Revision: http://reviews.llvm.org/D19119
llvm-svn: 266342
|
|
|
|
|
|
| |
registers.
llvm-svn: 266029
|
|
|
|
|
|
| |
operations.
llvm-svn: 266027
|
|
|
|
|
|
|
|
|
| |
Although repairing definitions is not mandatory for correctness (only
phis would be impacted because of the RPO traversal), not repairing
might go against the cost model. Therefore, just repair when it is
possible.
llvm-svn: 266025
|
|
|
|
|
|
|
|
| |
When assigning the register banks of an instruction, it is best to know
all the constraints of the input to have a good idea of how this will
impact the cost of the whole function.
llvm-svn: 265812
|
|
|
|
|
|
|
|
|
|
| |
Do not give that much importance to the current register bank of an
operand. This is likely just a side effect of the current execution and
it is properly wise to prefer a register bank that can be extracted from
the information available statically (like encoding constraints and
type).
llvm-svn: 265810
|