llvm-svn: 117057

llvm-svn: 116834

Get rid of static constructors for pass registration.  Instead, every pass exposes an initializeMyPassFunction(), which
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

llvm-svn: 116252

This time correctly.

llvm-svn: 116247

This reverts commit 116234.

It compiled just fine with MSVC and clang...

llvm-svn: 116242

llvm-svn: 116235

llvm-svn: 116234

llvm-svn: 115503

also fixes PR8250.

llvm-svn: 114972

llvm-svn: 114835

to link in "core".

llvm-svn: 114831

llvm-svn: 114830

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)

llvm-svn: 114795

unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies LLVM_INCLUDE_X

llvm-svn: 114747

llvm-svn: 114727

llvm-svn: 114725

Cameron Esfahani, tweaked to use array_lengthof.

llvm-svn: 114073

miscompiled by the system gcc-4.2.1

The test remains enabled for the second-stage test.

llvm-svn: 113824

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.

llvm-svn: 113187

llvm-svn: 112708

llvm-svn: 112189

Do unsigned char comparisons in StringRef::compare_lower to be more consistent with compare in corner cases.

llvm-svn: 112185

llvm-svn: 111539

Patch by Takumi Nakamura!

llvm-svn: 111270

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.

llvm-svn: 110909

 - 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.

llvm-svn: 110861

and removing it catches the mistake of passing a ValueMap by
copy rather than by reference.

llvm-svn: 110549

llvm-svn: 110504

llvm-svn: 110460

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

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

Fixes potential ambiguity problems on VS 2010.

Patch by nobled!

llvm-svn: 110029

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?".

llvm-svn: 109851

completed a successful build.

llvm-svn: 109815

llvm-svn: 109810

llvm-svn: 109809

angst.

llvm-svn: 109718

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