manifests itself when building LLVM with LTO.
<rdar://problem/10913281>

llvm-svn: 151576

llvm-svn: 150466

Module flags are key-value pairs associated with the module. They include a
'behavior' value, indicating how module flags react when mergine two
files. Normally, it's just the union of the two module flags. But if two module
flags have the same key, then the resulting flags are dictated by the behaviors.

Allowable behaviors are:

     Error
       Emits an error if two values disagree.

     Warning
       Emits a warning if two values disagree.

     Require
       Emits an error when the specified value is not present
       or doesn't have the specified value. It is an error for
       two (or more) llvm.module.flags with the same ID to have
       the Require behavior but different values. There may be
       multiple Require flags per ID.

     Override
       Uses the specified value if the two values disagree. It
       is an error for two (or more) llvm.module.flags with the
       same ID to have the Override behavior but different
       values.

llvm-svn: 150300

llvm-svn: 149967

llvm-svn: 148934

llvm-svn: 148802

System V Application Binary Interface. This lets us use
-fvisibility-inlines-hidden with LTO.
Fixes PR11697.

llvm-svn: 147624

to CloneFunctionInto to allow remapping for this case.

llvm-svn: 147217

the build bot in some cases.  The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type.  It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext.  We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.

Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is 
pretty great that way.

llvm-svn: 147010

merging types by name when we can.  We still don't guarantee type name linkage
but we do it when obviously the right thing to do.  This makes LTO type names 
easier to read, for example.

llvm-svn: 146932

fix PR11464 by preventing the linker from mapping two different struct types from the source module onto the same opaque destination type.  An opaque type can only be resolved to one thing or another after all.

llvm-svn: 146929

internal nightly testers.  Original commit message:

By popular demand, link up types by name if they are isomorphic and one is an
autorenamed version of the other.   This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large
app.

llvm-svn: 146838

autorenamed version of the other.   This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large app.

llvm-svn: 146728

Add support to the linker to lazily link in functions. This change only links functions marked with specific linkage (internal, private, linker_private, linker_private_weak, linker_private_weak_def_auto, linkonce, linkonce_odr, and available_externally) if they have uses in the destination module. Instead of automatically linking, these functions are placed onto a worklist to be processed in the final stage of linking. We iterate over the list and if any functions on the list have uses in the destination module, we link them in and repeat the process until no changes in the state (uses) has changed. This means that any functions in the LazilyLink worklist that have a use in the destination module will be linked in and none that don't. 

llvm-svn: 143524

llvm-svn: 143316

llvm-svn: 142010

Make it possible to use the linker without destroying the source module. This is so the source module can be linked to multiple other destination modules. For all that used LinkModules() before, they will continue to destroy the source module as before.

This line, and those below, will be ignored--

M    include/llvm/Linker.h
M    tools/bugpoint/Miscompilation.cpp
M    tools/bugpoint/BugDriver.cpp
M    tools/llvm-link/llvm-link.cpp
M    lib/Linker/LinkModules.cpp

llvm-svn: 141606

llvm-svn: 137482

llvm-svn: 136909

Migrate LLVM and Clang to use the new makeArrayRef(...) functions where previously explicit non-default constructors were used.
Mostly mechanical with some manual reformatting.

llvm-svn: 135390

llvm-svn: 135204

llvm-svn: 135183

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

llvm-svn: 128507

llvm-svn: 128506

llvm-svn: 128501

different visibilities.

llvm-svn: 124650

llvm-svn: 123529

llvm-svn: 123364

1. Take a flags argument instead of a bool.  This makes
   it more clear to the reader what it is used for.
2. Add a flag that says that "remapping a value not in the
   map is ok".
3. Reimplement MapValue to share a bunch of code and be a lot
   more efficient.  For lookup failures, don't drop null values
   into the map.
4. Using the new flag a bunch of code can vaporize in LinkModules
   and LoopUnswitch, kill it.

No functionality change.

llvm-svn: 123058

llvm-svn: 122637

llvm-svn: 122636

llvm-svn: 122632

llvm-svn: 122158

llvm-svn: 122157

the buildbots.

llvm-svn: 122149

llvm-svn: 122142

llvm-svn: 122141

llvm-svn: 120298

llvm-svn: 116788