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
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
since 2015 (n4387), though it's allowed by a library DR so new implementations
accept it in their C++11 modes...
This should unbreak the build with libstdc++ 4.9.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279583 91177308-0d34-0410-b5e6-96231b3b80d8
They really should have both types represented, but early variants were created
before MachineInstrs could have multiple types so they're rather ambiguous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279567 91177308-0d34-0410-b5e6-96231b3b80d8
Instructions like G_ICMP have multiple types that may need to be legalized (the
boolean output and nearly arbitrary inputs in this case). So the legalizer must
be capable of deciding what to do for each of them separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279554 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276461 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an (incomplete, inefficient) framework for deciding what to do with
some operation on a given type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276184 91177308-0d34-0410-b5e6-96231b3b80d8
