This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
I've tried to find main moudle headers where possible, but the TableGen
stuff may warrant someone else looking at it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169251 91177308-0d34-0410-b5e6-96231b3b80d8
isa<> et al. automatically infer when the cast is an upcast (including a
self-cast), so these are no longer necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165767 91177308-0d34-0410-b5e6-96231b3b80d8
structure and fix some fixmes. We now have a TreePredicateFn class
that handles all of the decoding of these things. This is an internal
cleanup that has no impact on the code generated by tblgen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129670 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenRegister entries. Use this information to more intelligently build
the literal register entires in the DAGISel matcher table. Specifically,
use a single-byte OPC_EmitRegister entry for registers with a value of
less than 256 and OPC_EmitRegister2 entry for registers with a larger value.
rdar://9066491
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127456 91177308-0d34-0410-b5e6-96231b3b80d8
for CheckValueTypeMatcher. The isContradictory implementation
helps us factor better, shrinking x86 table from 79144 -> 78896
bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97905 91177308-0d34-0410-b5e6-96231b3b80d8
as the very last thing before node emission. This should
dramatically reduce the number of times we do 'MatchAddress'
on X86, speeding up compile time. This also improves comments
in the tables and shrinks the table a bit, now down to
80506 bytes for x86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97703 91177308-0d34-0410-b5e6-96231b3b80d8
SwitchOpcodeMatcher) and have DAGISelMatcherOpt form it. This
speeds up selection, particularly for X86 which has lots of
variants of instructions with only type differences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97645 91177308-0d34-0410-b5e6-96231b3b80d8
stuff now that we don't care about emulating the old broken
behavior of the old isel. This eliminates the
'CheckChainCompatible' check (along with IsChainCompatible) which
did an incorrect and inefficient scan *up* the chain nodes which
happened as the pattern was being formed and does the validation
at the end in HandleMergeInputChains when it forms a structural
pattern. This scans "down" the graph, which means that it is
quickly bounded by nodes already selected. This also handles
token factors that get "trapped" in the dag.
Removing the CheckChainCompatible nodes also shrinks the
generated tables by about 6K for X86 (down to 83K).
There are two pieces remaining before I can nuke PreprocessRMW:
1. I xfailed a test because we're now producing worse code in a
case that has nothing to do with the change: it turns out that
our use of MorphNodeTo will leave dead nodes in the graph
which (depending on how the graph is walked) end up causing
bogus uses of chains and blocking matches. This is really
bad for other reasons, so I'll fix this in a follow-up patch.
2. CheckFoldableChainNode needs to be improved to handle the TF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97539 91177308-0d34-0410-b5e6-96231b3b80d8
This allows formation of OpcodeSwitch for top level patterns, in
particular on X86. This saves about 1K of data space in the x86
table and makes the dispatch much more efficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97440 91177308-0d34-0410-b5e6-96231b3b80d8
ComplexPattern at the root be generated multiple times, once
for each opcode they are part of. This encourages factoring
because the opcode checks get treated just like everything
else in the matcher.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97439 91177308-0d34-0410-b5e6-96231b3b80d8
to a scope where every child starts with a CheckOpcode, but
executes more efficiently. Enhance DAGISelMatcherOpt to
form it.
This also fixes a bug in CheckOpcode: apparently the SDNodeInfo
objects are not pointer comparable, we have to compare the
enum name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97438 91177308-0d34-0410-b5e6-96231b3b80d8
dispatcher method. This eliminates the dependence of the new isel's
generated code on the old isel's predicates, however some random
hand written isel code still uses them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97431 91177308-0d34-0410-b5e6-96231b3b80d8
specifies whether there is an output flag or not. Use this
instead of redundantly encoding the chain/flag results in the
output vtlist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97419 91177308-0d34-0410-b5e6-96231b3b80d8
even some the old isel didn't. There are several parts of
this that make me feel dirty, but it's no worse than the
old isel. I'll clean up the parts I can do without ripping
out the old one next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97415 91177308-0d34-0410-b5e6-96231b3b80d8
with getType() == MVT::i32 etc. Teach it that two different
integer constants are contradictory. This cuts 1K off the X86
table, down to 98k
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97314 91177308-0d34-0410-b5e6-96231b3b80d8
predicates. For example if we have:
Scope:
CheckType i32
ABC
CheckType f32
DEF
CheckType i32
GHI
Then we know that we can transform this into:
Scope:
CheckType i32
Scope
ABC
GHI
CheckType f32
DEF
This reorders the check for the 'GHI' predicate above
the check for the 'DEF' predidate. However it is safe to do this
in this situation because we know that a node cannot have both an
i32 and f32 type.
We're now doing more factoring that the old isel did.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97312 91177308-0d34-0410-b5e6-96231b3b80d8
as deeply into the pattern as we can get away with. In pratice, this
means "all the way to to the emitter code, but not across
ComplexPatterns". This substantially increases the amount of factoring
we get.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97305 91177308-0d34-0410-b5e6-96231b3b80d8
instead of to have a chained series of scope nodes. This makes
the generated table smaller, improves the efficiency of the
interpreter, and make the factoring optimization much more
reasonable to implement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97160 91177308-0d34-0410-b5e6-96231b3b80d8
reflect what it does. Switch the sense of the Next and the Check
arms to be more logical. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97093 91177308-0d34-0410-b5e6-96231b3b80d8
