Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
called. Provide an (asserting) definition of Operator's private destructor.
Remove destructors from all classes derived from Operator. We don't need them
for safety, because their implicit definitions would be ill-formed (they'd call
Operator's private destructor), and we don't need them to avoid emitting
vtables, because we don't do anything with Operator subclasses which would
trigger vtable instantiation.
The Operator hierarchy is still a complete disaster with regard to undefined
behavior, but this at least allows LLVM to link when using Clang's
-fcatch-undefined-behavior with a new vptr-based type checking mechanism.
llvm-svn: 166530
"Reinstate r133435 and r133449 (reverted in r133499) now that the clang
self-hosted build failure has been fixed (r133512)."
Due to some additional warnings.
llvm-svn: 133700
Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.
Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".
Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)
llvm-svn: 133435
I don't think the AugmentedUse struct buys us much, either in
correctness or in ease of use. Ditch it, and simplify Use::getUser() and
User::allocHungoffUses().
llvm-svn: 133433
Chandler Carruth