The previous names were both misleading (the MachineLegalizer actually
contained the info tables) and inconsistent with the selector & translator (in
having a "Machine") prefix. This should make everything sensible again.
The only functional change is the name of a couple of command-line options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284287 91177308-0d34-0410-b5e6-96231b3b80d8
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283671 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of producing a mapping for all the operands, we only generate a
mapping for the definition. Indeed, the other operands are not
constrained by the instruction and thus, we should leave the choice to
the actual definition to do the right thing.
In pratice this is almost NFC, but with one advantage. We will have only
one instance of OperandsMapping for each copy and phi that map to one
register bank instead of one different instance for each different
number of operands for each copy and phi.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282756 91177308-0d34-0410-b5e6-96231b3b80d8
This is a step toward statically allocate InstructionMapping. Like the
previous few commits, the goal is to move toward a TableGen'ed like
structure with no dynamic allocation at all.
This should already improve compile time by getting rid of a bunch of
memmove of SmallVectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282643 91177308-0d34-0410-b5e6-96231b3b80d8
Like partial mappings, as we move toward TableGen'ed information, the
number should reach zero eventually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282325 91177308-0d34-0410-b5e6-96231b3b80d8
This is a step toward statically allocate ValueMapping. Like the
previous few commits, the goal is to move toward a TableGen'ed like
structure with no dynamic allocation at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282324 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were using the address of the unique instance of a partial
mapping in the related map to access this instance. However, when the
map grows, the whole set of instances may be moved elsewhere and the
previous addresses are not valid anymore.
Instead, keep the address of the unique heap allocated instance of a
partial mapping.
Note: I did not see any actual bugs for that problem as the number of
partial mappings dynamically allocated is small (<= 4).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282323 91177308-0d34-0410-b5e6-96231b3b80d8
Collect statistics about the number of partial mappings dynamically
allocated and accessed. Ultimately, when the whole TableGen
infrastructure is set, those numbers should be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282274 91177308-0d34-0410-b5e6-96231b3b80d8
In the verify method of the ValueMapping class we used to check that the
mapping exactly matches the bits of the input value. This is problematic
for statically allocated mappings because we would need a different
mapping for each different size of the value that maps on one
instruction. For instance, with such scheme, we would need a different
mapping for a value of size 1, 5, 23 whereas they all end up on a 32-bit
wide instruction.
Therefore, change the verifier to check that the meaningful bits are
covered by the mapping instead of matching them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282214 91177308-0d34-0410-b5e6-96231b3b80d8
This is another step toward TableGen'ed like structures. The BreakDown of
the mapping of the value will be statically computed by TableGen, thus
we only have to point to the right entry in the table instead of
dynamically allocate the mapping for each instruction.
We still support the dynamic allocation through a factory of
PartialMapping to ease the bring-up of the targets while the TableGen
backend is not available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282213 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is basically the first step toward what will
RegisterBankInfo look when it gets TableGen'ed.
It introduces a XXXGenRegisterBankInfo.def file that is what TableGen
will issue at some point. Moreover, the RegBanks field in
RegisterBankInfo changed to reflect the static (compile time) aspect of
the information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282131 91177308-0d34-0410-b5e6-96231b3b80d8
When initializing an instance of OperandsMapper, instead of using
SmallVector::resize followed by std::fill, use the function that
directly does that in SmallVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282130 91177308-0d34-0410-b5e6-96231b3b80d8
We still don't really have an equivalent of "AssertXExt" in DAG, so we don't
exploit the guarantees on the receiving side yet, but this should produce
conservatively correct code on iOS ABIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282069 91177308-0d34-0410-b5e6-96231b3b80d8
The only implementation that exists immediately looks it up anyway, and the
information is needed to handle various parameter attributes (stored on the
function itself).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282068 91177308-0d34-0410-b5e6-96231b3b80d8
This should match the existing behaviour for passing complicated struct and
array types, in particular HFAs come through like that from Clang.
For C & C++ we still need to somehow support all the weird ABI flags, or at
least those that are present in the IR (signext, byval, ...), and stack-based
parameter passing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281977 91177308-0d34-0410-b5e6-96231b3b80d8
The OperandsMapper class is used heavy in RegBankSelect and each
instantiation triggered a heap allocation for the array of operands.
Instead, use a SmallVector with a big enough size such that most of the
cases do not have to use dynamically allocated memory.
This improves the compile time of the RegBankSelect pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281599 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise everything that needs to work out what size they are has to keep a
DataLayout handy, which is a bit silly and very annoying.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281597 91177308-0d34-0410-b5e6-96231b3b80d8
Unlike SDag, we use a separate G_GEP instruction (much simplified, only taking
a single byte offset) to preserve the pointer type information through
selection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281205 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions were only necessary when type information was stored in the
MachineInstr (because only generic MachineInstrs possessed a type). Now that
it's in MachineRegisterInfo, COPY and PHI work fine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281037 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281035 91177308-0d34-0410-b5e6-96231b3b80d8
They're another source of generic vregs, which are going to need a type on the
definition when we remove the register width from MachineRegisterInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280412 91177308-0d34-0410-b5e6-96231b3b80d8
More preparation for dropping source types from MachineInstrs: regsters coming
out of already-selected code (i.e. non-generic instructions) don't have a type,
but that information is needed so we must add it manually.
This is done via a new G_TYPE instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280292 91177308-0d34-0410-b5e6-96231b3b80d8
Legalization ends up creating many G_SEQUENCE/G_EXTRACT pairs which leads to
inefficient codegen (even for -O0), so add a quick pass over the function to
remove them again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280155 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of putting all possible requests into a single table, we can perform
the extremely dense lookup based on opcode and type-index in constant time
using multi-dimensional array-like things.
This roughly halves the time spent doing legalization, which was dominated by
queries against the Actions table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280011 91177308-0d34-0410-b5e6-96231b3b80d8
There should be no functional change here, I'm just making the implementation
of "frem" (to libcall) legalization easier for a followup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279987 91177308-0d34-0410-b5e6-96231b3b80d8
