must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
transformation collect all the addrecs with the same loop
add combine them at once rather than starting everything over
at the first chance.
llvm-svn: 112290
middle, copy the elements in two groups, rather than copying all the
elements and then doing an erase on the middle of the result. These
are SmallVectors, so we shouldn't expect to hit dynamic allocation
in the common case.
llvm-svn: 111151
having it finish processing all of the muliply operands before
starting the whole getAddExpr process over again, instead of
immediately after the first simplification.
llvm-svn: 110916
by having it finish processing the whole operand list before
starting the whole getAddExpr process over again, instead of
immediately after the first duplicate is found.
llvm-svn: 110914
of Value deletions and RAUWs, instead of relying on ScalarEvolution's
Scalars map being notified, as that's complicated at best, and
insufficient in general.
This means SCEVUnknown needs a non-trivial destructor, so introduce
a mechanism to allow ScalarEvolution to locate all the SCEVUnknowns.
llvm-svn: 110086
extend it to handle the case where multiple RAUWs affect a single
SCEVUnknown.
Add a ScalarEvolution unittest to test for this situation.
llvm-svn: 109705
object, as it may still be referenced by SCEVs not cleaned up by the
use list traversal.
Also, in ScalarEvolution::forgetValue, only check for a SCEVUnknown
object for the original value, not for any value in the use list,
because other SCEVUnknown values aren't necessary obsolete at that
point.
llvm-svn: 109570
Owen Anderson