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

Add verbose information when checking if the current and the desired
register banks match.
Detail what happens when we assign a register bank.

llvm-svn: 265804

Print the mask of the partial mapping as an hexadecimal instead of a
binary value.

llvm-svn: 265754

llvm-svn: 265749

helper class.

llvm-svn: 265747

class.

llvm-svn: 265746

Teach the target independent code how to take advantage of type
information to get the mapping of an instruction.

llvm-svn: 265739

specific type.

This will be used to find the default mapping of the instruction.
Also, this information is recorded, instead of computed, because it is
expensive from a type to know which register bank maps it.
Indeed, we need to iterate through all the register classes of all the
register banks to find the one that maps the given type.

llvm-svn: 265736

method.

NFC.

The refactoring intends to make the code more readable and expose
more features to potential derived classes.

llvm-svn: 265735

llvm-svn: 265733

from a register.
On top of duplicating the logic, it was buggy! It would assert on
physical registers, since MachineRegisterInfo does not have any
information regarding register classes/banks for them.

llvm-svn: 265727

The pass walk through the machine function and assign the register banks
using the default mapping. In other words, there is no attempt to reduce
cross register copies.

llvm-svn: 265707

the mapping of an instruction on register bank.

For most instructions, it is possible to guess the mapping of the
instruciton by using the encoding constraints.
It remains instructions without encoding constraints.
For copy-like instructions, we try to propagate the information we get
from the other operands. Otherwise, the target has to give this
information.

llvm-svn: 265703

the access to MRI and TRI.

llvm-svn: 265701

helper class.

The default constructor creates invalid (isValid() == false) instances
and may be used to communicate that a mapping was not found.

llvm-svn: 265699

llvm-svn: 265695

getInstrMapping.

This implementation requires that the target implemented
getRegBankFromRegClass.
Indeed, the implementation uses the register classes for the encoding
constraints for the instructions to deduce the mapping of a value.

llvm-svn: 265624

The previous method to get the size was too simple and could fail for
physical registers.

llvm-svn: 265620

This will be used by the register bank select pass to assign register banks
for generic virtual registers.

This was originally committed as r265573 but broke at least one windows bot.
The problem with the windows bot was that it was using a copy constructor for
the InstructionMappings class and could not synthesize it. Actually, the fact
that this class is not copy constructable is expected and the compiler should
use the move assignment constructor. Marking the problematic assignment
explicitly as using the move constructor has its own problems.

Indeed, with recent clang we get a warning that we may prevent the elision of
the copy by the compiler. A proper fix for both compilers would be to change the
API of getPossibleInstrMapping to take a InstructionMappings as input/output
parameter. This does not feel natural and since GISel is not used on windows
yet, I chose to workaround the problem by not compiling the problematic code on
windows.

llvm-svn: 265604

instruction on a register bank. This will be used by the register bank select
pass to assign register banks for generic virtual registers." and the follow-on
commits while I find out a way to fix the win7 bot:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19882

This reverts commit r265578, r265581, r265584, and r265585.

llvm-svn: 265587