/// FastEmit_f - This method is called by target-independent code
/// to request that an instruction with the given type, opcode, and
/// floating-point immediate operand be emitted.
virtual unsigned FastEmit_f(MVT VT,
MVT RetVT,
unsigned Opcode,
const ConstantFP *FPImm);
Currently, it emits an accidentally overloaded version without the const on the
ConstantFP*. This doesn't affect anything in the tree, since nothing causes that
method to be autogenerated, but I have been playing with some ARM TableGen
refactorings that hit this problem.
llvm-svn: 147727
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().
Delete the old manual, error-prone implementations in the targets.
llvm-svn: 146873
Teach TableGen to create the missing register classes needed for
getMatchingSuperRegClass() to return maximal results. The function is
still not auto-generated, so it still returns inexact results.
This produces these new register classes:
ARM:
QQPR_with_dsub_0_in_DPR_8
QQQQPR_with_dsub_0_in_DPR_8
X86:
GR64_with_sub_32bit_in_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOSP
GR64_with_sub_16bit_in_GR16_NOREX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX
GR64_TC_and_GR64_with_sub_32bit_in_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX_NOSP
GR64_TCW64_and_GR64_with_sub_32bit_in_GR32_NOAX
GR64_TC_and_GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX
GR64_with_sub_32bit_in_GR32_TC
GR64_with_sub_32bit_in_GR32_ABCD_and_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_TC
GR64_with_sub_32bit_in_GR32_AD
GR64_with_sub_32bit_in_GR32_AD_and_GR32_NOAX
The other targets in the tree are not weird enough to be affected.
llvm-svn: 146872
The function TRI::getCommonSubClass(A, B) returns the largest common
sub-class of the register classes A and B. This patch teaches TableGen
to synthesize sub-classes such that the answer is always maximal.
In other words, every register that is in both A and B will also be
present in getCommonSubClass(A, B).
This introduces these synthetic register classes:
ARM:
GPRnopc_and_hGPR
GPRnopc_and_hGPR
hGPR_and_rGPR
GPRnopc_and_hGPR
GPRnopc_and_hGPR
hGPR_and_rGPR
tGPR_and_tcGPR
hGPR_and_tcGPR
X86:
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR64_NOSP_and_GR64_TC
GR64_NOSP_and_GR64_TC
GR64_NOREX_and_GR64_TC
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR64_NOSP_and_GR64_TC
GR64_NOREX_and_GR64_TC
GR64_NOREX_NOSP_and_GR64_TC
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR32_ABCD_and_GR32_NOAX
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR32_ABCD_and_GR32_NOAX
GR32_NOAX_and_GR32_TC
GR32_NOAX_and_GR32_NOSP
GR64_NOSP_and_GR64_TC
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR64_NOREX_and_GR64_TC
GR64_NOREX_NOSP_and_GR64_TC
GR32_ABCD_and_GR32_NOAX
GR64_ABCD_and_GR64_TC
GR32_NOAX_and_GR32_TC
GR32_AD_and_GR32_NOAX
Other targets are unaffected.
llvm-svn: 146657
For example, ARM allows:
vmov.u32 s4, #0 -> vmov.i32, #0
'u32' is a more specific designator for the 32-bit integer type specifier
and is legal for any instruction which accepts 'i32' as a datatype suffix.
We want to say,
def : TokenAlias<".u32", ".i32">;
This works by marking the match class of 'From' as a subclass of the
match class of 'To'.
rdar://10435076
llvm-svn: 145992
1. Added opcode BUNDLE
2. Taught MachineInstr class to deal with bundled MIs
3. Changed MachineBasicBlock iterator to skip over bundled MIs; added an iterator to walk all the MIs
4. Taught MachineBasicBlock methods about bundled MIs
llvm-svn: 145975
one aspect of them by having them use the (annoying, if not broken)
proper library dependency model for adding the LLVMTableGen library as
a dependency. This could manifest as a link order issue in the presence
of separate LLVM / Clang source builds with CMake and a linker that
really cares about such things.
Also, add the Support dependency to llvm-tblgen itself so that it
doesn't rely on TableGen's transitive Support dependency. A parallel
change for clang-tblgen will be forthcoming.
llvm-svn: 143531
For example,
On ARM, "mov r3, #-3" is an alias for "mvn r3, #2", so we want to use a
matcher pattern that handles the bitwise negation when mapping to t2MVNi.
llvm-svn: 143233
If the register class in the source alias is a subclass of the register class
of the actual instruction, the alias can still match OK since the constraints
are strictly a subset of what the instruction can actually handle.
llvm-svn: 143200
Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.
Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.
llvm-svn: 142670
NEON immediates are "interesting". Start of the work to handle parsing them
in an 'as' compatible manner. Getting the matcher to play nicely with
these and the floating point immediates from VFP is an extra fun wrinkle.
llvm-svn: 142293
TableGen infers unmodeled side effects on instructions without a
pattern. Fix some instruction definitions where that was overlooked.
Also raise an error if a rematerializable instruction has unmodeled side
effects. That doen't make any sense.
llvm-svn: 141929
The table is indexed by opcode, so simply removing pseudo-instructions
creates a wrong mapping from opcode to table entry.
Add a test case for xorps which has a very high opcode that exposes this
problem.
llvm-svn: 141562
This restores my karma after I added TRI::getSubClassWithSubReg().
Register constraints are applied 'backwards'. Starting from the
register class required by an instruction operand, the correct question
is: 'How can I constrain the super-register register class so all its
sub-registers satisfy the instruction constraint?' The
getMatchingSuperRegClass() hook answers that.
We never need to go 'forwards': Starting from a super-register register
class, what register class are the sub-registers in? The
getSubRegisterRegClass() hook did that.
llvm-svn: 141258
This function is used to constrain a register class to a sub-class that
supports the given sub-register index.
For example, getSubClassWithSubReg(GR32, sub_8bit) -> GR32_ABCD.
The function will be used to compute register classes when emitting
INSERT_SUBREG and EXTRACT_SUBREG nodes and for register class inflation
of sub-register operations.
The version provided by TableGen is usually adequate, but targets can
override.
llvm-svn: 141142
The set of register classes should be closed under sub-register
operations and intersections. That will allow the register allocator to
model combinations of constraints accurately.
This patch implements the easiest form of register class inference: For
every register class, and for every sub-register SubIdx, the subset of
registers in RC that have a SubIdx sub-register should also be a register
class.
This does create some new register classes for the targets in the tree:
ARM gets a new QQQQPR_with_ssub_0. This class was omitted from the .td
file on purpose because it only has two registers. InstrEmitter and
RegisterCoalescer have safeguards against selecting too small register
classes, so it is harmless.
PowerPC gets a G8RC_with_sub_32 class because LR is not a sub_32
sub-register of LR8. I think that might be an omission?
X86 puts RIP in the GR64 class, and since that register doesn't have
8-bit sub-registers, we get:
GR64_with_sub_8bit
GR64_TC_with_sub_8bit
GR64_NOREX_with_sub_8bit
GR64_TC_with_sub_8bit_hi
The various CodeGen classes have already been fixed so adding new
register classes should not affect compile time.
llvm-svn: 141084
When TableGen starts creating its own register classes, the synthesized
classes won't have a Record reference. All register classes must have a
name, though.
llvm-svn: 141081
This uses less memory and it reduces the complexity of sub-class
operations:
- hasSubClassEq() and friends become O(1) instead of O(N).
- getCommonSubClass() becomes O(N) instead of O(N^2).
In the future, TableGen will infer register classes. This makes it
cheap to add them.
llvm-svn: 140898
All register classes are given a lower ID than their sub-classes.
Cliques are ordered alphabetically.
This will be used to simplify some sub-class operations.
llvm-svn: 140826
