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

Evan's help with the rest.

llvm-svn: 46697

llvm-svn: 46696

llvm-svn: 46695

stores to be deleted in some cases.

llvm-svn: 46694

llvm-svn: 46693

llvm-svn: 46688

llvm-svn: 46687

llvm-svn: 46684

reassociate anyways, but they could be generated during instcombine's run.

llvm-svn: 46683

llvm-svn: 46682

llvm-svn: 46681

multiple times due to a RAUW.

llvm-svn: 46680