| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Refactor a helper function, FactorNodes, to search for a push node in constant space. This resolves a problem in a not-yet-upstreamed backend where a recursive pattern blew the call stack (at a depth of 255) under a debug build of tablegen. No functional change so no new test coverage. The change is minimal to avoid disturbing existing behaviour.
Differential Revision: https://reviews.llvm.org/D29080
llvm-svn: 294230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ScopeMatcher we're working on is also a ScopeMatcher, merge all its children into the one we're working on.
There were several cases in X86 where we were unable to fully factor a ScopeMatcher but created nested ScopeMatchers for some portions of it. Then we created a SwitchType that split it up and further factored it so that we ended up with something like this:
SwitchType
Scope
Scope
Sequence of matchers
Some other sequence of matchers
EndScope
Another sequence of matchers
EndScope
...Next type
This change turns it into this:
SwitchType
Scope
Sequence of matchers
Some other sequence of matchers
Another sequence of matchers
EndScope
...Next type
Several other in-tree targets had similar nested scopes like this. Overall this doesn't save many bytes, but makes the isel output a little more regular.
llvm-svn: 287624
|
|
|
|
|
|
|
|
|
|
| |
creation of SwitchTypeMatcher.
Previously we were factoring when the ScopeMatcher was initially created, but it might get more Matchers added to it later. Delay factoring until we have fully created/populated the ScopeMatchers.
This reduces X86 isel tables by 154 bytes.
llvm-svn: 287520
|
|
|
|
| |
llvm-svn: 268712
|
|
|
|
|
|
| |
Pattern predicates already appear to be emitted as far down as they can be. The optimization was making no changes on any in-tree target.
llvm-svn: 268705
|
|
|
|
|
|
|
|
|
| |
This opcode never happens in practice, and yet the logic we have in
place to handle it would be undefined behaviour if we ever executed
it. Remove it rather than trying to refactor code that's never
reached.
llvm-svn: 268692
|
|
|
|
|
|
| |
forming a SwitchType node. Remove a couple hundred bytes from the X86 matcher table.
llvm-svn: 268611
|
|
|
|
| |
llvm-svn: 268610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed some unused headers, replaced some headers with forward class declarations.
Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'
Patch by Eugene Kosov <claprix@yandex.ru>
Differential Revision: http://reviews.llvm.org/D19219
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
|
|
|
|
| |
llvm-svn: 224224
|
|
|
|
|
|
|
|
|
|
|
|
| |
self-associative containers
StringSet is still a bit dodgy in that it exposes the raw iterator of
the StringMap parent, which exposes the weird detail that StringSet
actually has a 'value'... but anyway, this is useful for a handful of
clients that want to reference the newly inserted/persistent string data
in the StringSet/Map/Entry/thing.
llvm-svn: 222302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just fixing comments, no functional change.
Test Plan: N/A
Reviewers: jfb
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D5130
llvm-svn: 216784
|
|
|
|
|
|
|
|
|
|
|
| |
".reset()"
It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.
llvm-svn: 213438
|
|
|
|
|
|
| |
definition below all of the header #include lines, TableGen edition.
llvm-svn: 206846
|
|
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206254
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203083
|
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
| |
from X86 matcher table.
llvm-svn: 200821
|
|
|
|
| |
llvm-svn: 199712
|
|
|
|
|
|
| |
of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon.
llvm-svn: 192026
|
|
|
|
| |
llvm-svn: 191941
|
|
|
|
|
|
| |
of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon.
llvm-svn: 191940
|
|
|
|
| |
llvm-svn: 130068
|
|
|
|
| |
llvm-svn: 122513
|
|
|
|
| |
llvm-svn: 122506
|
|
|
|
|
|
| |
in some more places.
llvm-svn: 99366
|
|
|
|
|
|
| |
have enums for them.
llvm-svn: 98597
|
|
|
|
| |
llvm-svn: 97912
|
|
|
|
| |
llvm-svn: 97911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now it will factor things like this:
CheckType i32
...
CheckOpcode ISD::AND
CheckType i64
...
into:
SwitchType:
i32: ...
i64:
CheckOpcode ISD::AND
...
This shrinks hte table by a few bytes, nothing spectacular.
llvm-svn: 97908
|
|
|
|
|
|
|
|
| |
SwitchOpcodeMatcher) and have DAGISelMatcherOpt form it. This
speeds up selection, particularly for X86 which has lots of
variants of instructions with only type differences.
llvm-svn: 97645
|
|
|
|
|
|
|
|
| |
(set GPR, somecomplexpattern)
if somecomplexpattern doesn't declare what it can match.
llvm-svn: 97513
|
|
|
|
| |
llvm-svn: 97510
|
|
|
|
| |
llvm-svn: 97508
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 97439
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 97438
|
|
|
|
|
|
|
| |
pair. This encourages MorphNodeTo formation, this gets us 200
more MorphNodeTo's on X86 and shrinks the table a bit.
llvm-svn: 97434
|
|
|
|
|
|
| |
slot they're recording into, no functionality change.
llvm-svn: 97433
|
|
|
|
|
|
|
|
|
|
|
| |
so that we get grouping at the top level.
Add an optimization to reorder type check & record nodes
after opcode checks. We prefer to expose tree shape
matching which improves grouping and will enhance the next
optimization.
llvm-svn: 97432
|
|
|
|
|
|
| |
the vtlist for emitnode.
llvm-svn: 97429
|
|
|
|
|
|
|
|
| |
specifies whether there is an output flag or not. Use this
instead of redundantly encoding the chain/flag results in the
output vtlist.
llvm-svn: 97419
|
|
|
|
|
|
| |
is just a silly wrapper around MorphNodeTo.
llvm-svn: 97416
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 97415
|
|
|
|
|
|
| |
it will populate.
llvm-svn: 97363
|
|
|
|
|
|
| |
because I have to go on another detour first.
llvm-svn: 97362
|
|
|
|
|
|
| |
the opcode name. This gives the optimizer more semantic info.
llvm-svn: 97346
|
|
|
|
| |
llvm-svn: 97315
|
|
|
|
|
|
|
|
| |
with getType() == MVT::i32 etc. Teach it that two different
integer constants are contradictory. This cuts 1K off the X86
table, down to 98k
llvm-svn: 97314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 97312
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 97305
|