llvm-svn: 112924

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.

llvm-svn: 99797

llvm-svn: 99796

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.

llvm-svn: 99795

comment in the generated table.

llvm-svn: 99794

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.

llvm-svn: 98999

llvm-svn: 98904

changing the primary datastructure from being a 
"std::vector<unsigned char>" to being a new TypeSet class
that actually has (gasp) invariants!

This changes more things than I remember, but one major
innovation here is that it enforces that named input 
values agree in type with their output values.

This also eliminates code that transparently assumes (in 
some cases) that SDNodeXForm input/output types are the
same, because this is wrong in many case.

This also eliminates a bug which caused a lot of ambiguous
patterns to go undetected, where a register class would
sometimes pick the first possible type, causing an
ambiguous pattern to get arbitrary results.

With all the recent target changes, this causes no 
functionality change!

llvm-svn: 98534

to itself, even though this isn't wildly useful.

llvm-svn: 97574

llvm-svn: 97556

(set GPR, somecomplexpattern)

if somecomplexpattern doesn't declare what it can match.

llvm-svn: 97513

ordered correctly.  Previously it would get in trouble when
two patterns were too similar and give them nondet ordering.
We force this by using the record ID order as a fallback.

The testsuite diff is due to alpha patterns being ordered
slightly differently, the change is a semantic noop afaict:

< 	lda $0,-100($16)
---
> 	subq $16,100,$0

llvm-svn: 97509

llvm-svn: 97504

llvm-svn: 97486

with a release-asserts build on x86-64-darwin10:

LLC Size:
Old: 15,426,852
New: 12,759,140  (down 2.7M)

LLI Size:
Old: 9,926,876
New: 8,864,292   (down 1.1M)

X86ISelDAGToDAG.o size:
Old: 1,401,232
New:   162,868   (down 1.3M)

Time to build X86ISelDAGToDAG.o:
Old: 67.147u 2.060s 1:09.78
New:  4.234u 0.387s 0:04.77

llvm-svn: 97475

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

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.

llvm-svn: 97431

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

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.

llvm-svn: 97160

llvm-svn: 97096

reflect what it does.  Switch the sense of the Next and the Check
arms to be more logical.  No functionality change.

llvm-svn: 97093

llvm-svn: 97034

the old one around for comparative purposes: have the
ENABLE_NEW_ISEL #define (which is not enabled on mainline) stop
emitting the old isel at all, yay for build time win.

llvm-svn: 97033

the new isel: fold movechild+record+moveparent into a
single recordchild N node.  This shrinks the X86 table
from 125443 to 117502 bytes.

llvm-svn: 97031

Also add an easy macro at the top of DAGISelEmitter.cpp to enable
it.  Lets see if I can avoid accidentally turning it on :)

llvm-svn: 97029

least cost matches.  This gets us from 195 -> 208 passes on the ppc codegen tests.

llvm-svn: 96747

llvm-svn: 96725

of the matched pattern to use the newly created node results.  Onto
the "making it actually work" phase!

llvm-svn: 96724

the point where it is to the 95% feature complete mark, it just
needs result updating to be done (then testing, optimization 
etc).

More specificallly, this adds support for chain and flag handling
on the result nodes, support for sdnodexforms, support for variadic
nodes, memrefs, pinned physreg inputs, and probably lots of other
stuff.

In the old DAGISelEmitter, this deletes the dead code related to
OperatorMap, cleans up a variety of dead stuff handling "implicit
remapping" from things like globaladdr -> targetglobaladdr (which
is no longer used because globaladdr always needs to be legalized),
and some minor formatting fixes.

llvm-svn: 96716

Nothing real here yet.

llvm-svn: 96575

llvm-svn: 96541

llvm-svn: 96497

and add a sparc implementation that knows about delay slots.  Patch by
Nathan Keynes!

llvm-svn: 96492

tblgen splatted code into the implementation.

llvm-svn: 96460

functionality change.

llvm-svn: 96453

for evaluating complex patterns.  Some cleanup has to happen before
this can be used though.

llvm-svn: 96419

does the same thing as getComplexPatternInfo.

llvm-svn: 96411

llvm-svn: 96409

into a roundss intrinsic, producing a cyclic dag.  The root cause
of this is badness handling ComplexPattern nodes in the old dagisel
that I noticed through inspection.  Eliminate a copy of the of the
code that handled ComplexPatterns by making EmitChildMatchCode call
into EmitMatchCode.

llvm-svn: 96408

with chains.  On interior nodes that lead up to them, we just directly
check that there is a single use.  This generates slightly more
efficient code.

llvm-svn: 96366