patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

  vec.insert(vec.begin(), vec[3]);
The issue was that vec[3] returns a reference into the vector, which is invalidated when insert() memmove's the elements down to make space.  The method needs to specifically detect and handle this case to correctly match std::vector's semantics.

Thanks to Howard Hinnant for clarifying the correct behavior, and explaining how std::vector solves this problem.

llvm-svn: 134554

llvm-svn: 133648

all over the place in different styles and variants.  Standardize on two
preferred entrypoints: one that takes a StructType and ArrayRef, and one that
takes StructType and varargs.

In cases where there isn't a struct type convenient, we now add a
ConstantStruct::getAnon method (whose name will make more sense after a few
more patches land).  

It would be "really really nice" if the ConstantStruct::get and 
ConstantVector::get methods didn't make temporary std::vectors.

llvm-svn: 133412

much cleaner.

llvm-svn: 133364

llvm-svn: 133195

Follow up to r133032.

llvm-svn: 133107

llvm-svn: 133081

llvm-svn: 133075

use these soon.

llvm-svn: 131812

can be used to turn a <4 x i64> into a <4 x i32> but getCastOpcode would assert
if you passed these types to it.  Note that this strictly extends the previous
functionality: if getCastOpcode previously accepted two vector types (i.e. didn't
assert) then it still will and returns the same opcode (BitCast).  That's because
before it would only accept vectors with the same bitwidth, and the new code only
touches vectors with the same length.  However if two vectors have both the same
bitwidth and the same length then their element types have the same bitwidth, so
the new logic will return BitCast as before.

llvm-svn: 131530

gcc.

Fixes PR9886.

llvm-svn: 131181

Remove bounded StringRef::compare() since nothing but Clang SA was using it and it is just as easy to use StringRef::substr() preceding StringRef::compare() to achieve the same thing.

llvm-svn: 130430

llvm-svn: 129932

Implements StringRef::compare with bounds. It is behaves similarly to strncmp(). Unit tests also included. 

llvm-svn: 129582

llvm-svn: 129271

had gotten out of sync: isCastable didn't think it was possible to
cast the x86_mmx type to anything, while it did think it possible
to cast an i64 to x86_mmx.

llvm-svn: 128705

llvm-svn: 128622

Avoid turning a floating point division with a constant power of two into a denormal multiplication.

Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.

llvm-svn: 128555

The idea is, that if an ieee 754 float is divided by a power of two, we can
turn the division into a cheaper multiplication. This function sees if we can
get an exact multiplicative inverse for a divisor and returns it if possible.

This is the hard part of PR9587.

I tested many inputs against llvm-gcc's frotend implementation of this
optimization and didn't find any difference. However, floating point is the
land of weird edge cases, so any review would be appreciated.

llvm-svn: 128545

PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128537

llvm-svn: 128535

Add an argument to APInt's magic udiv calculation to specify the number of bits that are known zero in the divided number.

This will come in handy soon.

llvm-svn: 127828

Patch by Erik Olofsson!

llvm-svn: 126796

should be that if the phi is used by a side-effect free instruction with
no uses then the phi and the instruction now get zapped (checked by the
unittest).

llvm-svn: 126124

of a constant had a minor typo introduced when copying it from the book, which
caused it to favor negative approximations over positive approximations in many
cases. Positive approximations require fewer operations beyond the multiplication.

In the case of division by 3, we still generate code that is a single instruction
larger than GCC's code.

llvm-svn: 126097

Requires CMake 2.8.3 or newer.

llvm-svn: 126092

test for that. With this change, test/CodeGen/X86/codegen-dce.ll no longer finds
any instructions to DCE, so delete the test.

Also renamed J and JP to I and IP in RecursivelyDeleteDeadPHINode.

llvm-svn: 126088

by Andrew Clinton!

llvm-svn: 126077

on the host OS.  Reviewed by dgregor.

llvm-svn: 125406

by Clang.

llvm-svn: 124871

the loop.

llvm-svn: 124784

may be useful to understand "none", this is not the place for it.  Tweak
the fix to Normalize while there: the fix added in 123990 works correctly,
but I like this way better.  Finally, now that Triple understands some
non-trivial environment values, teach the unittests about them.

llvm-svn: 124720

Don't infinitely recurse!  Patch by Marius Wachtler!

llvm-svn: 124366

Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure.

llvm-svn: 123990

llvm-svn: 123546

llvm-svn: 123529

llvm-svn: 123377

llvm-svn: 123358

Add a unnamed_addr bit to global variables and functions. This will be used
to indicate that the address is not significant and therefore the constant
or function can be merged with others.

If an optimization pass can show that an address is not used, it can set this.

Examples of things that can have this set by the FE are globals created to
hold string literals and C++ constructors.

Adding unnamed_addr to a non-const global should have no effect unless
an optimization can transform that global into a constant.

Aliases are not allowed to have unnamed_addr since I couldn't figure
out any use for it.

llvm-svn: 123063