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
available targets unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies
LLVM_INCLUDE_X"
It breaks the configuration phase when cmake is invoked without
parameters, it is too complex for the purpose and introduces an
incovenience for the user (as both LLVM_BUILD_X and LLVM_INCLUDE_X
must set to OFF for not including X on the build)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114795 91177308-0d34-0410-b5e6-96231b3b80d8
Fix zeroExtend and signExtend to support empty sets, and to return the smallest
possible result set which contains the extension of each element in their
inputs. For example zext i8 [100, 10) to i16 is now [0, 256), not i16 [100, 10)
which contains 63446 members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113187 91177308-0d34-0410-b5e6-96231b3b80d8
target triple and straightens it out. This does less than gcc's script
config.sub, for example it turns i386-mingw32 into i386--mingw32 not
i386-pc-mingw32, but it does a decent job of turning funky triples into
something that the rest of the Triple class can understand. The plan
is to use this to canonicalize triple's when they are first provided
by users, and have the rest of LLVM only deal with canonical triples.
Once this is done the special case workarounds in the Triple constructor
can be removed, making the class more regular and easier to use. The
comments and unittests for the Triple class are already adjusted in this
patch appropriately for this brave new world of increased uniformity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110909 91177308-0d34-0410-b5e6-96231b3b80d8
- remove ashr which never worked.
- fix lshr and shl and add tests.
- remove dead function "intersect1Wrapped".
- add a new sub method to subtract ranges, with test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110861 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
handles with a pointer to the containing map. When a map is copied, these
pointers need to be corrected to point to the new map. If not, then consider
the case of a map M1 which maps a value V to something. Create a copy M2 of
M1. At this point there are two value handles on V, one representing V as a
key in M1, the other representing V as a key in M2. But both value handles
point to M1 as the containing map. Now delete V. The value handles remove
themselves from their containing map (which destroys them), but only the first
value handle is successful: the second one cannot remove itself from M1 as
(once the first one has removed itself) there is nothing there to remove; it
is therefore not destroyed. This causes an assertion failure "All references
to V were not removed?".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109851 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
rip out the implementation of X86InstrInfo::GetInstSizeInBytes.
The code being ripped out just implemented a copy and hacked up
version of the (old) instruction encoder, and is buggy and
terrible in other ways. Since "GetInstSizeInBytes" is really
only there to support the JIT's "NeedsExactSize" hook (which
noone is using), just rip out the code. I will rip out the
NeedsExactSize hook next.
This resolves rdar://7617809 - switch X86InstrInfo::GetInstSizeInBytes to use X86MCCodeEmitter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109149 91177308-0d34-0410-b5e6-96231b3b80d8
