When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.
This works well because TableGen resolves member references late:
class I : Instruction {
AddrMode AM = AddrModeNone;
let TSFlags{3-0} = AM.Value;
}
let AM = AddrMode4 in
def ADD : I;
TSFlags gets the expected bits from AddrMode4 in this example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100384 91177308-0d34-0410-b5e6-96231b3b80d8
backend (ARMDecoderEmitter) which emits the decoder functions for ARM and Thumb,
and the disassembler core which invokes the decoder function and builds up the
MCInst based on the decoded Opcode.
Reviewed by Chris Latter and Bob Wilson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100233 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't need to be stable because the patterns are fully ordered.
Add a first level sort predicate that orders patterns in this
order: 1) scalar integer operations 2) scalar floating point
3) vector int 4) vector float. This is a trivial sort on their
top level pattern type so it is nice and transitive. The
benefit of doing this is that simple integer operations are
much more common than insane vector things and isel was trying
to match the big complex vector patterns before the simple
ones because the complexity of the vector operations was much
higher. Since they can't both match, it is best (for compile
time) to try the simple integer ones first.
This cuts down the # failed match attempts on real code by
quite a bit, for example, this reduces backtracks on crafty
(as a random example) from 228285 -> 188369.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99797 91177308-0d34-0410-b5e6-96231b3b80d8
patterns within the generated matcher. This works great except
that the sort fails because the relation defined isn't
transitive. I have a much simpler solution coming next, but want
to archive the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99795 91177308-0d34-0410-b5e6-96231b3b80d8
and those derived from them. These are obnoxious because
they were written as: PatLeaf<(bitconvert). Not having an
argument was foiling adding better type checking for operand
count matching up with what was required (in this case,
bitconvert always requires an operand!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99759 91177308-0d34-0410-b5e6-96231b3b80d8
transforming it into (add (i32 GPR), 4). This allows us to write type
generic multi patterns and have tblgen automatically drop the bitconvert
in the case when the types align. This allows us to fold an extra load
in the changed testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99756 91177308-0d34-0410-b5e6-96231b3b80d8
1, 1 cases which are by-far the most frequent. This shrinks the X86
isel table from 77014 -> 74657 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99740 91177308-0d34-0410-b5e6-96231b3b80d8
issues to get here. We now trim the result type list of the
CompleteMatch or MorphNodeTo operation to be the same size as the
thing we're matching. this means that if you match (add GPR, GPR)
with an instruction that produces a normal result and a flag that
we now trim the result in tblgen instead of having to do it
dynamically. This exposed a bunch of inconsistencies in result
counting that happened to be getting lucky since the days of the
old isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99728 91177308-0d34-0410-b5e6-96231b3b80d8
same vt multiple times for a register. For example,
ECX is in 5 different i32 reg classes, just return
1 i32 instead of 5.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99727 91177308-0d34-0410-b5e6-96231b3b80d8
from two places in CodeGenDAGPatterns.cpp, and
use it in DAGISelMatcherGen.cpp instead of using
an incorrect predicate that happened to get lucky
on our current targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99726 91177308-0d34-0410-b5e6-96231b3b80d8
results forward. We can now handle an instruction that
produces one implicit def and one result instead of one or
the other when not at the root of the pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99725 91177308-0d34-0410-b5e6-96231b3b80d8
Remove much horribleness from X86InstrFormats as a result. Similar
simplifications are probably possible for other targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99539 91177308-0d34-0410-b5e6-96231b3b80d8
bytes instead of one byte. This is important because
we're running up to too many opcodes to fit in a byte
and it is aggrevated by FIRST_TARGET_MEMORY_OPCODE
making the numbering sparse. This just bites the
bullet and bloats out the table. In practice, this
increases the size of the x86 isel table from 74.5K
to 76K. I think we'll cope :)
This fixes rdar://7791648
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99494 91177308-0d34-0410-b5e6-96231b3b80d8
If a TableGen class has an initializer expression containing an X.Y subexpression,
AND X depends on template parameters,
AND those template parameters have defaults,
AND some parameters with defaults are beyond position 1,
THEN parts of the initializer expression are evaluated prematurely with the default values when the first explicit template parameter is substituted, before the remaining explicit template parameters have been substituted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99492 91177308-0d34-0410-b5e6-96231b3b80d8
of runs without leak checking. We add -vg to the triple for non-checked runs,
or -vg_leak for checked runs. Also use this to XFAIL the TableGen tests, since
tablegen leaks like a sieve. This includes some valgrindArgs refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99103 91177308-0d34-0410-b5e6-96231b3b80d8
to maintain a list of types (one for each result of
the node) instead of a single type. There are liberal
hacks added to emulate the old behavior in various
situations, but they can start disolving now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98999 91177308-0d34-0410-b5e6-96231b3b80d8
