- change isShuffleMaskLegal to show that all shuffles with 32-bit and 64-bit
elements are legal
- the Neon shuffle instructions do not support 64-bit elements, but we were
not checking for that before lowering shuffles to use them
- remove some 64-bit element vduplane patterns that are no longer needed
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105586 91177308-0d34-0410-b5e6-96231b3b80d8
encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105539 91177308-0d34-0410-b5e6-96231b3b80d8
In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105524 91177308-0d34-0410-b5e6-96231b3b80d8
VECTOR_SHUFFLEs to REG_SEQUENCE instructions. The standard ISD::BUILD_VECTOR
node corresponds closely to REG_SEQUENCE but I couldn't use it here because
its operands do not get legalized. That is pretty awful, but I guess it
makes sense for other targets. Instead, I have added an ARM-specific version
of BUILD_VECTOR that will have its operands properly legalized.
This fixes the rest of Radar 7872877.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105439 91177308-0d34-0410-b5e6-96231b3b80d8
A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105413 91177308-0d34-0410-b5e6-96231b3b80d8
instruction defines subregisters.
Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.
Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:
%reg1234:foo = FLAP %reg1234<imp-def>
will reMaterialize(%reg3333, bar) like this:
%reg3333:bar-foo = FLAP %reg333:bar<imp-def>
Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105358 91177308-0d34-0410-b5e6-96231b3b80d8
backends and removes the virtual declaration. With that out of the way
I should be able to cleanup one backend at a time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105321 91177308-0d34-0410-b5e6-96231b3b80d8
x86 backend currently doesn't know how to handle them.
This doesn't really fix anything because LegalizeTypes doesn't know how to
handle them either. We do get a better error message, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105305 91177308-0d34-0410-b5e6-96231b3b80d8
were overspecified when inheriting sub-subregisters, for instance:
R0Q:subreg_even32 = R0Q:subreg_32bit = R0Q:subreg_even:subreg_32bit.
This meant that composeSubRegIndices(subreg_even, subreg_32bit) was ambiguous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105063 91177308-0d34-0410-b5e6-96231b3b80d8
