This is similar to the StringToOffsetTable we use to produce string
tables, but it can be used for other sequences than strings, and it
eliminates entries for suffixes.
llvm-svn: 153760
The arm_neon intrinsics can create virtual registers from the DPair
register class which allows both even-odd and odd-even D-register pairs.
This fixes PR12389.
llvm-svn: 153603
We cannot limit the concatenated instruction names to 64K. ARM is
already at 32K, and it is easy to imagine a target with more
instructions.
llvm-svn: 152817
This patch limited the concatenated register names to 64K which meant
that the total number of registers was many times less than 64K.
If any compilers actually enforce the 64K limit on string literals, and
it turns out to be a problem, we should fix that problem by not using
long string literals.
llvm-svn: 152816
~0U might be i32 on 32-bit hosts, then (uint64_t)~0U might not be expected as (i64)0xFFFFFFFF_FFFFFFFF, but as (i64)0x00000000_FFFFFFFF.
llvm-svn: 152407
Original commit message:
Use uint16_t to store InstrNameIndices in MCInstrInfo. Add asserts to protect all 16-bit string table offsets. Also make sure the string to offset table string is not larger than 65536 characters since larger string literals aren't portable.
llvm-svn: 152296
Original commit message:
Use uint16_t to store InstrNameIndices in MCInstrInfo. Add asserts to protect
all 16-bit string table offsets. Also make sure the string to offset table
string is not larger than 65536 characters since larger string literals aren't
portable.
llvm-svn: 152233
With the new composite physical registers to represent arbitrary pairs
of DPR registers, we don't need the pseudo-registers anymore. Get rid of
a bunch of them that use DPR register pairs and just use the real
instructions directly instead.
llvm-svn: 152045
- Shrink the opcode field to 16 bits.
- Shrink the AsmVariantID field to 8 bits.
- Store the mnemonic string in a string table, store a 16 bit index.
- Store a pascal-style length byte in the string instead of a null terminator,
so we can avoid calling strlen on every entry we visit during mnemonic search.
Shrinks X86AsmParser.o from 434k to 201k on x86_64 and eliminates relocs from the table.
llvm-svn: 151984
Allows us to de-virtualize the function and provides access to it in
the instruction printer, which is useful for handling composite
physical registers (e.g., ARM register lists).
llvm-svn: 151815
This reverts commit 151760.
We want to move getSubReg() from TargetRegisterInfo into MCRegisterInfo,
but to do that, the type of the lookup table needs to be the same for
all targets.
llvm-svn: 151814
This allows us to make TRC non-polymorphic and value-initializable, eliminating a huge static
initializer and a ton of cruft from the generated code.
Shrinks ARMBaseRegisterInfo.o by ~100k.
llvm-svn: 151806
- The search bounds are constant, in the worst case (ARM target) it will scan over 30 uint16_ts.
- This method isn't very hot, I had problems finding a testcase where it's called more than a dozen of times (no perf impact).
llvm-svn: 151773
Instead of nested switch statements, use a lookup table. On ARM, this replaces
a 23k (x86_64 release build) function with a 16k table. Its not unlikely to
be faster, as well.
llvm-svn: 151751
This requires some gymnastics to make it available for C code. Remove the names
from the disassembler tables, making them relocation free.
llvm-svn: 150303
Make them accessible through MCInstrInfo. They are only used for debugging purposes so this doesn't
have an impact on performance. X86MCTargetDesc.o goes from 630K to 461K on x86_64.
llvm-svn: 150245
When adding the {-1, -1} entry to the DFAStateInputTable, we
need to increment the index used to populate the DFAStateEntryTable.
Otherwise, the entry table will be off by one for each transition
after the {-1, -1} entry. PR11908.
llvm-svn: 149713
It is simpler to define a composite index directly:
def ssub_2 : SubRegIndex<[dsub_1, ssub_0]>;
def ssub_3 : SubRegIndex<[dsub_1, ssub_1]>;
Than specifying the composite indices on each register:
CompositeIndices = [(ssub_2 dsub_1, ssub_0),
(ssub_3 dsub_1, ssub_1)] in ...
This also makes it clear that SubRegIndex composition is supposed to be
unique.
llvm-svn: 149556
The final tie breaker comparison also needs to return +/-1, or 0.
This is not a less() function.
This could cause otherwise identical super-classes to be ordered
unstably, depending on what the system qsort routine does with a bad
compare function.
llvm-svn: 149549
This class is used to represent SubRegIndex instances instead of the raw
Record pointers that were used before.
No functional change intended.
llvm-svn: 149418
When set, this bit indicates that a register is completely defined by
the value of its sub-registers.
Use the CoveredBySubRegs property to infer which super-registers are
call-preserved given a list of callee-saved registers. For example, the
ARM registers D8-D15 are callee-saved. This now automatically implies
that Q4-Q7 are call-preserved.
Conversely, Win64 callees save XMM6-XMM15, but the corresponding
YMM6-YMM15 registers are not call-preserved because they are not fully
defined by their sub-registers.
llvm-svn: 148363
Targets can now add CalleeSavedRegs defs to their *CallingConv.td file.
TableGen will use this to create a *_SaveList array suitable for
returning from getCalleeSavedRegs() as well as a *_RegMask bit mask
suitable for returning from getCallPreservedMask().
llvm-svn: 148346
(This time I believe I've checked all the -Wreturn-type warnings from GCC & added the couple of llvm_unreachables necessary to silence them. If I've missed any, I'll happily fix them as soon as I know about them)
llvm-svn: 148262
/// 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
Many targets use pseudo instructions to help register allocation. Like
the COPY instruction, these pseudos can be expanded after register
allocation. The early expansion can make life easier for PEI and the
post-ra scheduler.
This patch adds a hook that is called for all remaining pseudo
instructions from the ExpandPostRAPseudos pass.
llvm-svn: 140472
No functionality change. The hook makes it explicit which patterns
require "special" handling. i.e. it self-documents tblgen
deficiencies. I plan to add verification in ExpandISelPseudos and
Thumb2SizeReduce to catch any missing hasPostISelHooks. Otherwise it's
too fragile.
llvm-svn: 140160
Modified ARMISelLowering::AdjustInstrPostInstrSelection to handle the
full gamut of CPSR defs/uses including instructins whose "optional"
cc_out operand is not really optional. This allowed removal of the
hasPostISelHook to simplify the .td files and make the implementation
more robust.
Fixes rdar://10137436: sqlite3 miscompile
llvm-svn: 140134
The immediate offset of the non-writeback i8 form (encoding T4) allows
negative offsets only. The positive offset form of the encoding is the
LDRT instruction. Immediate offsets in the range [0,255] use encoding T3
instead.
llvm-svn: 139254
Store a RecordVal's name as an Init to allow class-qualified Record
members to reference Records that have Init names. We'll use this to
provide more programmability in how we name defs and their associated
members.
llvm-svn: 139031
Add a instruction flag: hasPostISelHook which tells the pre-RA scheduler to
call a target hook to adjust the instruction. For ARM, this is used to
adjust instructions which may be setting the 's' flag. ADC, SBC, RSB, and RSC
instructions have implicit def of CPSR (required since it now uses CPSR physical
register dependency rather than "glue"). If the carry flag is used, then the
target hook will *fill in* the optional operand with CPSR. Otherwise, the hook
will remove the CPSR implicit def from the MachineInstr.
llvm-svn: 138810
Add the predicate operand to the instructions. Update the back end
accordingly where the instructions are used. Restrict the SP operands
to actually only be SP, as otherwise these break assembly parsing for the
normal instruction variants.
llvm-svn: 138445
It turns out that the use of "__extension__" in these macros was disabling
the expected "incompatible pointer" warnings, so these type checks were not
doing anything anyway. They introduced a serious bug by evaluating some
macro arguments twice, which is a big problem for arguments with side effects.
I'll have to find another way to get the right type checking. Radar 9947657.
llvm-svn: 137680
Allow a target assembly parser to do context sensitive constraint checking
on a potential instruction match. This will be used, for example, to handle
Thumb2 IT block parsing.
llvm-svn: 137675
Use an Init (ultimately a StringInit) to represent the Record name.
This allows the name to be composed by standard TableGen operators.
This will enable us to get rid of the ugly #NAME# hack processing and
naturally replace it with operators. It also increases flexibility
and power of the TableGen language by allowing record identifiers to
be computed dynamically.
llvm-svn: 137232
Add a method to return an Init as an unquoted string. This primarily
affects StringInit where we return the value without surrounding it
with quotes.
This is in preparation for removing the ugly #NAME# hack and replacing
it with standard TabelGen operators.
llvm-svn: 137231
This new disassembler can correctly decode all the testcases that the old one did, though
some "expected failure" testcases are XFAIL'd for now because it is not (yet) as strict in
operand checking as the old one was.
llvm-svn: 137144
Memory operand parsing is a bit haphazzard at the moment, in no small part
due to the even more haphazzard representations of memory operands in the .td
files. Start cleaning that all up, at least a bit.
The addressing modes in the .td files will be being simplified to not be
so monolithic, especially with regards to immediate vs. register offsets
and post-indexed addressing. addrmode3 is on its way with this patch, for
example.
This patch is foundational to enable going back to smaller incremental patches
for the individual memory referencing instructions themselves. It does just
enough to get the basics in place and handle the "make check" regression tests
we already have.
Follow-up work will be fleshing out the details and adding more robust test
cases for the individual instructions, starting with ARM mode and moving from
there into Thumb and Thumb2.
llvm-svn: 136845
Make sure TernOpInits are unique and created only once. This will be
important for AVX/SIMD as many operators will be used to generate
patterns and other relevant data.
llvm-svn: 136496
Make sure BinOpInits are unique and created only once. This will be
important for AVX/SIMD as many operators will be used to generate
patterns and other relevant data.
llvm-svn: 136495
Make sure UnOpInits are unique and created only once. This will be
important for AVX/SIMD as many operators will be used to generate
patterns and other relevant data.
llvm-svn: 136494
Ensure ListInits are unique and only created once. This will be
important for AVX as lists will be used extensively to pass generic
patterns, prefix information and other things to lower-level
pattern-generation classes.
llvm-svn: 136493
Use a StringMap to ensure the StringInits are unique. This is
especially important for AVX where we will have many smallish
strings representing instruction prefixes, suffixes and the like.
llvm-svn: 136491
Remove all non-const iterators from Init classes. This is another
step toward constifying Inits and ultimately turning them into
FoldingSetNodes.
llvm-svn: 136484
Create a std::string wrapper for use as a DenseMap key. DenseMap is
not safe in generate with strings, so this wrapper indicates that only
strings guaranteed not to have certain values should be used in the
DenseMap.
llvm-svn: 136481
This can happen in cases where TableGen generated asm matcher cannot check
whether a register operand is in the right register class. e.g. mem operands.
rdar://8204588
llvm-svn: 136292
llvm-mc gives an "invalid operand" error for instructions that take an unsigned
immediate which have the high bit set such as:
pblendw $0xc5, %xmm2, %xmm1
llvm-mc treats all x86 immediates as signed values and range checks them.
A small number of x86 instructions use the imm8 field as a set of bits.
This change only changes those instructions and where the high bit is not
ignored. The others remain unchanged.
llvm-svn: 136287
This makes TargetRegisterClass slightly slower. Next step will be making contains faster.
Eventually TargetRegisterClass will be killed entirely.
llvm-svn: 135835
The immediate is in the range 1-32, but is encoded as 0-31 in a 5-bit bitfield.
Update the representation such that we store the operand as 0-31, allowing us
to remove the encoder method and the special case handling in the disassembler.
Update the assembly parser and the instruction printer accordingly.
llvm-svn: 135823
Move the shift operator and special value (32 encoded as 0 for PKHTB) handling
into the instruction printer. This cleans up a bit of the disassembler
special casing for these instructions, more easily handles not printing the
operand at all for "lsl #0" and prepares for correct asm parsing of these
operands.
llvm-svn: 135626
Add range checking for the immediate operand and handle the "mov" mnemonic
choosing between encodings based on the value of the immediate. Add tests
for fixups, encoding choice and values, and diagnostic for out of range values.
llvm-svn: 135500
to MCRegisterInfo. Also initialize the mapping at construction time.
This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.
llvm-svn: 135424
Original Log: Get rid of the separate opcodes for the Darwin versions of tBL, tBLXi, and tBLXr, using pseudo-instructions to lower to the single final opcode. Update the ARM disassembler for this change.
llvm-svn: 135414
Make all of the RecTy constructors private, and use get() factory
methods instead. Return singleton instances when it makes sense.
ListTy instance pointers are stored in the element RecTy instance.
BitsRecTy instance pointers, one per length, are stored in a static vector.
Also unique DefInit instances. A Record has a unique DefInit which
has a unique RecordRecTy instance.
This saves some 200k-300k RecTy allocations when parsing ARM.td. It
reduces TableGen's heap usage by almost 50%.
llvm-svn: 135399
- The actual values are from the MCOI::OperandType enum.
- Teach tblgen to read it from the instruction definition.
- This is a better implementation of the hacks in edis.
llvm-svn: 135197
Manage Inits in a FoldingSet. This provides several benefits:
- Memory for Inits is properly managed
- Duplicate Inits are folded into Flyweights, saving memory
- It enforces const-correctness, protecting against certain classes
of bugs
The above benefits allow Inits to be used in more contexts, which in
turn provides more dynamism to TableGen. This enhanced capability
will be used by the AVX code generator to a fold common patterns
together.
llvm-svn: 134907
The enum names as well as order (i.e. value)
had skewed, which means that consumers of the
tablegen-ed table would see different values than
intended. Make both files have a superset of enums,
and add classification as needed for numMCOperands.
Reviewed by Owen Anderson
llvm-svn: 134905
and MCSubtargetInfo.
- Added methods to update subtarget features (used when targets automatically
detect subtarget features or switch modes).
- Teach X86Subtarget to update MCSubtargetInfo features bits since the
MCSubtargetInfo layer can be shared with other modules.
- These fixes .code 16 / .code 32 support since mode switch is updated in
MCSubtargetInfo so MC code emitter can do the right thing.
llvm-svn: 134884
This allows the (many) pseudo-instructions we have that map onto a single
real instruction to have their expansion during MC lowering handled
automatically instead of the current cumbersome manual expansion required.
These sorts of pseudos are common when an instruction is used in situations
that require different MachineInstr flags (isTerminator, isBranch, et. al.)
than the generic instruction description has. For example, using a move
to the PC to implement a branch.
llvm-svn: 134704
- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
to generate asm matcher subtarget feature queries. e.g.
"ModeThumb,FeatureThumb2" is translated to
"(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".
llvm-svn: 134678
So users of a CGI don't have to look up the value directly from the original
Record; just like the rest of the convenience values in the class.
llvm-svn: 134576
For now this is distinct from isCodeGenOnly, as code-gen-only
instructions can (and often do) still have encoding information
associated with them. Once we've migrated all of them over to true
pseudo-instructions that are lowered to real instructions prior to
the printer/emitter, we can remove isCodeGenOnly and just use isPseudo.
llvm-svn: 134539
itineraries.
- Refactor TargetSubtarget to be based on MCSubtargetInfo.
- Change tablegen generated subtarget info to initialize MCSubtargetInfo
and hide more details from targets.
llvm-svn: 134257
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
llvm-svn: 134127
Unlike Thumb1, Thumb2 does not have dedicated encodings for adjusting the
stack pointer. It can just use the normal add-register-immediate encoding
since it can use all registers as a source, not just R0-R7. The extra
instruction definitions are just duplicates of the normal instructions with
the (not well enforced) constraint that the source register was SP.
llvm-svn: 134114
The tSpill and tRestore instructions are just copies of the tSTRspi and
tLDRspi instructions, respectively. Just use those directly instead.
llvm-svn: 134092
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
Correctly parse the forms of the Thumb mov-immediate instruction:
1. 8-bit immediate 0-255.
2. 12-bit shifted-immediate.
The 16-bit immediate "movw" form is also legal with just a "mov" mnemonic,
but is not yet supported. More parser logic necessary there due to fixups.
llvm-svn: 133966
Sorry, this was a bad idea. Within clang these builtins are in a separate
"ARM" namespace, but the actual builtin names should clearly distinguish that
they are target specific.
llvm-svn: 133832
This caused linker errors when linking both libLLVMX86Desc and libLLVMX86CodeGen
into a single binary (for example when building a monolithic libLLVM shared library).
llvm-svn: 133791
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
llvm-svn: 133782
A RegisterTuples instance is used to synthesize super-registers by
zipping together lists of sub-registers. This is useful for generating
pseudo-registers representing register sequence constraints like 'two
consecutive GPRs', or 'an even-odd pair of floating point registers'.
The RegisterTuples def can be used in register set operations when
building register classes. That is the only way of accessing the
synthesized super-registers.
For example, the ARM QQ register class of pseudo-registers could have
been formed like this:
// Form pairs Q0_Q1, Q2_Q3, ...
def QQPairs : RegisterTuples<[qsub_0, qsub_1],
[(decimate QPR, 2),
(decimate (shl QPR, 1), 2)]>;
def QQ : RegisterClass<..., (add QQPairs)>;
Similarly, pseudo-registers representing '3 consecutive D-regs with
wraparound' look like:
// Form D0_D1_D2, D1_D2_D3, ..., D30_D31_D0, D31_D0_D1.
def DSeqTriples : RegisterTuples<[dsub_0, dsub_1, dsub_2],
[(rotl DPR, 0),
(rotl DPR, 1),
(rotl DPR, 2)]>;
TableGen automatically computes aliasing information for the synthesized
registers.
Register tuples are still somewhat experimental. We still need to see
how they interact with MC.
llvm-svn: 133407
Targets that need to change the default allocation order should use the
AltOrders mechanism instead. See the X86 and ARM targets for examples.
The allocation_order_begin() and allocation_order_end() methods have been
replaced with getRawAllocationOrder(), and there is further support
functions in RegisterClassInfo.
It is no longer possible to insert arbitrary code into generated
register classes. This is a feature.
llvm-svn: 133332
A register class can define AltOrders and AltOrderSelect instead of
defining method protos and bodies. The AltOrders lists can be defined
with set operations, and TableGen can verify that the alternative
allocation orders only contain valid registers.
This is currently an opt-in feature, and it is still possible to
override allocation_order_begin/end. That will not be true for long.
llvm-svn: 133320
At the time I wrote this code (circa 2007), TargetRegisterInfo was using a std::set to perform these queries. Switching to the static hashtables was an obvious improvement, but in reality there's no reason to do anything other than scan.
With this change, total LLC time on a whole-program 403.gcc is reduced by approximately 1.5%, almost all of which comes from a 15% reduction in LiveVariables time. It also reduces the binary size of LLC by 86KB, thanks to eliminating a bunch of very large static tables.
llvm-svn: 133051
This prepares tablegen to compute register lists from set theoretic dag
expressions. This doesn't really make any difference as long as
Target.td still declares RegisterClass::MemberList as [Register].
llvm-svn: 133043
Make the Elements vector private and expose an ArrayRef through
getOrder() instead. getOrder will eventually provide multiple
user-specified allocation orders.
Use the sorted member set for member and subclass tests. Clean up a lot
of ad hoc searches.
llvm-svn: 133040
Measure the worst case number of probes for a miss instead of the less
conservative number of probes required for an insertion.
Lower the limit to < 6 probes worst case.
This doubles the size of the ARM and X86 hash tables, other targets are
unaffected. LiveVariables runs 12% faster with this change.
<rdar://problem/9598545>
llvm-svn: 132999
Make the hash tables as small as possible while ensuring that all
lookups can be done in less than 8 probes.
Cut the aliases hash table in half by only storing a < b pairs - it
is a symmetric relation.
Use larger multipliers on the initial hash function to ensure that it
properly covers the whole table, and to resolve some clustering in the
very regular ARM register bank.
This reduces the size of most of these tables by 4x - 8x. For instance,
the ARM tables shrink from 48 KB to 8 KB.
llvm-svn: 132888
The constant hash tables for sub-registers and overlaps are generated
the same way, so extract a function to generate and print the hash
table.
Also use the information computed by CodeGenRegisters.cpp instead of the
locally data.
llvm-svn: 132886
Besides moving structural computations to CodeGenRegisters.cpp, this
also well-defines the order of these lists:
- Sub-register lists come from a pre-order traversal of the graph
defined by the SubRegs lists in the .td files.
- Super-register lists are topologically ordered so no register comes
before any of its sub-registers. When the sub-register graph is not a
tree, independent super-registers appear in numerical order.
- Lists of overlapping registers are ordered according to register
number.
This reverses the order of the super-regs lists, but nobody was
depending on that. The previous order of the overlaps lists was odd, and
it may have depended on the precise behavior of std::stable_sort.
The old computations are still there, but will be removed shortly.
llvm-svn: 132881
I'll be moving some more code there to gather all of the
register-specific stuff in one place. Currently it is shared between
CodeGenTarget and RegisterInfoEmitter.
The plan is that CodeGenRegisters can compute the full register bank
structure while RegisterInfoEmitter only will handle the printing part.
llvm-svn: 132788
Jakob Stoklund Olesen