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

keep the LegalizeTypes node flags up to date when doing a RAUW.
This fixes a nasty bug that Duncan ran into and makes the 
previous (nonbuggy case) more efficent.

llvm-svn: 46679

llvm-svn: 46678

DAGUpdateListener object pointer instead of just returning a vector 
of deleted nodes.  This makes the interfaces more efficient (no more
allocating a vector [at least a malloc], filling it in, then walking
it) and more clean.  This also allows the client to be notified of
nodes that are *changed* but not deleted.

llvm-svn: 46677

llvm-svn: 46676

SelectionDAG::ReplaceAllUsesWith to handle replacement of
an SDOperand with *any* sdoperand, not just one for a node with
a single result.  Note that this has a horrible FIXME'd hack in it
to work around PR1975.  This should be removed when PR1975 is fixed.

llvm-svn: 46674

llvm-svn: 46673

llvm-svn: 46672

llvm-svn: 46667

llvm-svn: 46666

llvm-svn: 46665

SDIsel processes llvm.dbg.declare by recording the variable debug information descriptor and its corresponding stack frame index in MachineModuleInfo. This only works if the local variable is "homed" in the stack frame. It does not work for byval parameter, etc.
Added ISD::DECLARE node type to represent llvm.dbg.declare intrinsic. Now the intrinsic calls are lowered into a SDNode and lives on through out the codegen passes.
For now, since all the debugging information recording is done at isel time, when a ISD::DECLARE node is selected, it has the side effect of also recording the variable. This is a short term solution that should be fixed in time.

llvm-svn: 46659

llvm-svn: 46658

llvm-svn: 46657

than double through the C bindings. Thanks to Tomas Lindquist
Olsen for reporting it.

llvm-svn: 46656