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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46727 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46717 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46706 91177308-0d34-0410-b5e6-96231b3b80d8
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].
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46705 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46679 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46677 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46674 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46659 91177308-0d34-0410-b5e6-96231b3b80d8
