llvm-svn: 46818

llvm-svn: 46817

This is not ready for review or hacking, this is a work in progress :)

llvm-svn: 46816

RegAllocaLocal still *requires* LiveVariables since it runs PHIElimination, followed by TwoAddress which requires LiveVariables. We cannot run LiveVariables on non-SSA code.

llvm-svn: 46813

llvm-svn: 46810

Throttle the non-local dependence analysis for basic blocks with more than 50 predecessors. Added command line option to play with this threshold.

llvm-svn: 46790

llvm-svn: 46781

llvm-svn: 46776

Move to getCALLSEQ_END to ensure CALLSEQ_END node produces a flag. This is consistent with the definition in td file.

llvm-svn: 46775

check more intelligent.  This speeds up mem2reg from 5.29s to 
0.79s on a synthetic testcase with tons of predecessors and
phi nodes.

llvm-svn: 46767

llvm-svn: 46764

If a vr is already marked alive in a bb, then it has PHI uses that are visited earlier, then it is not killed in the def block (i.e. not dead).

llvm-svn: 46763

llvm-svn: 46761

dependencies in makefile, and fix llvm_cv_no_link_all_option
on darwin.

Patch by Shantonu Sen, more info here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-February/012410.html

llvm-svn: 46760

llvm-svn: 46757

unique ImutAVLTree* for profiling.

Modified ImutAVLTree:
 (1) changed ComputeHash() to ComputeDigest() and
 (2) changed Profile() to use the computed digest and
 (3) modified insertion of IMutAVLTree into the FoldingSet owned by
     the ImutAVLTreeFactory object to use profiling instead of computing
     a direct hash.  This fixes a bug where our abuse of the FoldingSet would
     not work when the FoldingSet was resized.

llvm-svn: 46753

llvm-svn: 46746

llvm-svn: 46741

was incorrectly simplifying "x == (gep x, 1, i)" into false, even 
though i could be negative.  As it turns out, all the code to 
handle this already existed, we just need to disable the incorrect
optimization case and let the general case handle it.

llvm-svn: 46739

llvm-svn: 46738

llvm-svn: 46733

llvm-svn: 46730

llvm-svn: 46729

vec_ext_v4si builtins.  This is a hack; they should
be defined here, then resolved in the X86 BE.
However there is enough other stuff missing in the
X86 BE for SSE41 that this will do for now.

llvm-svn: 46727

llvm-svn: 46725

Dwarf requires variable entries to be in the source order. Right now, since we are recording variable information at isel time this means parameters would appear in the reverse order. The short term fix is to issue recordVariable() at asm printing time instead.

llvm-svn: 46724

llvm-svn: 46723

llvm-svn: 46720

of the contained ImutAVLTree root.

llvm-svn: 46719

llvm-svn: 46718

node in the FoldingSet of nodes held by the Factory object.  If we
we find a node with a matching hash, we do a full structural comparison.
Nodes are also now inserted into the FoldingSet only when we mark them
Immutable, as their children can change during intermediate-rebalancing.

The 'Profile' method for ImutAVLTree is no longer used when looking up
existing ImutAVLTrees with a given set of contents; instead the Profile method
is used by other clients that wish to insert such a tree into a folding set.
This means that we are not using FoldingSet in ImutAVLTreeFactory in the way
it was intended, but instead are using it as an opaque hashtable.

llvm-svn: 46717

over all the nodes in a particular bucket.

llvm-svn: 46716

Patch by Shantonu Sen.

llvm-svn: 46715

expand the result of this operator!" (node: ctlz).

llvm-svn: 46713

this operator's operand" (node: extract_subvector).

llvm-svn: 46712

llvm-svn: 46711

llvm-svn: 46709

llvm-svn: 46707

any bugs in the future since to get the crash you also
need hacked in fake libcall support (which creates odd
but legal trees), but since adding it doesn't hurt...
Thanks to Chris for this ultimately reduced version.

llvm-svn: 46706

ReadyToProcess node - add an assertion to check
this.  Add an assertion to NodeDeleted that checks
that processed/ready nodes are indeed not deleted.
It is because they are never deleted that none of
the maps can have a deleted node as the source of
a mapping.  It does however seem to be possible in
theory to have a deleted value as the target of a
mapping, however this has not yet been spotted in
the wild.  Still mulling on what to do about this.
[The theoretical situation is this: a node A is
expanded/promoted/whatever to a newly created node
B.  Thus A->B is added to a map.  When the subtree
rooted at B is legalized it is conceivable that B
is deleted due to RAUW on a node somewhere above
it].

llvm-svn: 46705