they may have ValuesAtScopes map entries referencing their outer loops.
This fixes a user-after-free reported in PR8471.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117698 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116820 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116334 91177308-0d34-0410-b5e6-96231b3b80d8
all applicable addrecs before recursing on getMulExpr, instead of
recursing on getMulExpr for each one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112433 91177308-0d34-0410-b5e6-96231b3b80d8
transformation collect all the addrecs with the same loop
add combine them at once rather than starting everything over
at the first chance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112290 91177308-0d34-0410-b5e6-96231b3b80d8
return to avoid needing two calls to test for equivalence, and sort
addrecs by their degree before examining their operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112267 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111151 91177308-0d34-0410-b5e6-96231b3b80d8
when they are the same loop. Don't compare two instructions'
loop depths when they are in the same block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111045 91177308-0d34-0410-b5e6-96231b3b80d8
having it finish processing all of the muliply operands before
starting the whole getAddExpr process over again, instead of
immediately after the first simplification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110914 91177308-0d34-0410-b5e6-96231b3b80d8
make any assumptions about when the two conditions will agree on when
to permit the loop to exit. This fixes PR7845.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110758 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110086 91177308-0d34-0410-b5e6-96231b3b80d8
extend it to handle the case where multiple RAUWs affect a single
SCEVUnknown.
Add a ScalarEvolution unittest to test for this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109705 91177308-0d34-0410-b5e6-96231b3b80d8
