by switching CachedFunctionInfo from a std::map to a
ValueMap (which is implemented in terms of a DenseMap).
DenseMap has different iterator invalidation semantics
than std::map.
This should hopefully fix the dragonegg builder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101658 91177308-0d34-0410-b5e6-96231b3b80d8
const_casts, and it reinforces the design of the Target classes being
immutable.
SelectionDAGISel::IsLegalToFold is now a static member function, because
PIC16 uses it in an unconventional way. There is more room for API
cleanup here.
And PIC16's AsmPrinter no longer uses TargetLowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101635 91177308-0d34-0410-b5e6-96231b3b80d8
CGSCC can delete nodes in regions of the callgraph that
have already been visited. If new CG nodes are allocated
to the same pointer, we shouldn't abort, just handle it
correctly by assigning a new number. This should restore
stability by removing invalidated pointers that *will* be
reused from the densemap in the iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101628 91177308-0d34-0410-b5e6-96231b3b80d8
the live-in sets of BBs in the loop. Otherwise later pass may end up using the
registers and override the invariant. rdar://7852937
No reasonablly sized test case possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101626 91177308-0d34-0410-b5e6-96231b3b80d8
- LLVMgold.so --> libLLVMgold.so
- the GCC LTO project is no longer 'upcoming'
- document the plugin support for 'ar' and 'nm'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101624 91177308-0d34-0410-b5e6-96231b3b80d8
may be called when either the source or destination type is i64, and my
change also hadn't fixed the most obvious problem -- assuming that i64 will
only be bitconverted to f64, ignoring the various vector types.
Radar 7873160.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101615 91177308-0d34-0410-b5e6-96231b3b80d8
to determine where to place PHIs by iteratively comparing reaching definitions
at each block. That was just plain wrong. This version now computes the
dominator tree within the subset of the CFG where PHIs may need to be placed,
and then places the PHIs in the iterated dominance frontier of each definition.
The rest of the patch is mostly the same, with a few more performance
improvements added in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101612 91177308-0d34-0410-b5e6-96231b3b80d8
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101579 91177308-0d34-0410-b5e6-96231b3b80d8
to keep the node entries in scc_iterator up to date instead of dangling as
the SCC mutates.
This is a really terrible problem which was causing -g to affect codegen
because it would permute the memory image of the compiler process.
Thanks to Dale for expertly hunting it down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101565 91177308-0d34-0410-b5e6-96231b3b80d8
use of that option with it. This eliminates an imprecise "Linux"
test, and should help support old versions of gold.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101560 91177308-0d34-0410-b5e6-96231b3b80d8
to CallGraphSCCPass's instead of passing around a
std::vector<CallGraphNode*>. No functionality change,
but now we have a much tidier interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101558 91177308-0d34-0410-b5e6-96231b3b80d8
case. Also, the 0xFF hex literal involved in the shift for ESize64 should be
suffixed "ul" to preserve the shift result.
Implemented printHex*ImmOperand() by copying from ARMAsmPrinter.cpp and added a
test case for DisassembleN1RegModImmFrm()/printHex64ImmOperand().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101557 91177308-0d34-0410-b5e6-96231b3b80d8
