2009-03-03 18:04:23 +08:00
|
|
|
//===- lib/Linker/LinkModules.cpp - Module Linker Implementation ----------===//
|
2005-04-22 06:55:34 +08:00
|
|
|
//
|
2004-11-13 04:37:43 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-22 06:55:34 +08:00
|
|
|
//
|
2004-11-13 04:37:43 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the LLVM module linker.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2004-11-15 07:27:04 +08:00
|
|
|
#include "llvm/Linker.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm-c/Linker.h"
|
2012-02-11 19:38:06 +08:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2012-01-06 07:02:01 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2012-02-11 19:38:06 +08:00
|
|
|
#include "llvm/ADT/SetVector.h"
|
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Constants.h"
|
|
|
|
#include "llvm/DerivedTypes.h"
|
|
|
|
#include "llvm/Instructions.h"
|
|
|
|
#include "llvm/Module.h"
|
2012-03-23 04:28:27 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2010-11-30 02:16:10 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2012-03-23 04:28:27 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2011-10-11 08:24:54 +08:00
|
|
|
#include "llvm/Transforms/Utils/Cloning.h"
|
2010-08-25 02:50:07 +08:00
|
|
|
#include "llvm/Transforms/Utils/ValueMapper.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/TypeFinder.h"
|
2012-03-03 17:36:58 +08:00
|
|
|
#include <cctype>
|
2004-11-13 04:37:43 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// TypeMap implementation.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2008-06-17 05:00:18 +08:00
|
|
|
namespace {
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
class TypeMapTy : public ValueMapTypeRemapper {
|
|
|
|
/// MappedTypes - This is a mapping from a source type to a destination type
|
|
|
|
/// to use.
|
|
|
|
DenseMap<Type*, Type*> MappedTypes;
|
|
|
|
|
|
|
|
/// SpeculativeTypes - When checking to see if two subgraphs are isomorphic,
|
|
|
|
/// we speculatively add types to MappedTypes, but keep track of them here in
|
|
|
|
/// case we need to roll back.
|
|
|
|
SmallVector<Type*, 16> SpeculativeTypes;
|
|
|
|
|
2011-12-20 08:03:52 +08:00
|
|
|
/// SrcDefinitionsToResolve - This is a list of non-opaque structs in the
|
|
|
|
/// source module that are mapped to an opaque struct in the destination
|
|
|
|
/// module.
|
|
|
|
SmallVector<StructType*, 16> SrcDefinitionsToResolve;
|
|
|
|
|
|
|
|
/// DstResolvedOpaqueTypes - This is the set of opaque types in the
|
|
|
|
/// destination modules who are getting a body from the source module.
|
|
|
|
SmallPtrSet<StructType*, 16> DstResolvedOpaqueTypes;
|
2012-03-23 04:30:41 +08:00
|
|
|
|
2008-06-17 07:06:51 +08:00
|
|
|
public:
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// addTypeMapping - Indicate that the specified type in the destination
|
|
|
|
/// module is conceptually equivalent to the specified type in the source
|
|
|
|
/// module.
|
|
|
|
void addTypeMapping(Type *DstTy, Type *SrcTy);
|
|
|
|
|
|
|
|
/// linkDefinedTypeBodies - Produce a body for an opaque type in the dest
|
|
|
|
/// module from a type definition in the source module.
|
|
|
|
void linkDefinedTypeBodies();
|
|
|
|
|
|
|
|
/// get - Return the mapped type to use for the specified input type from the
|
|
|
|
/// source module.
|
|
|
|
Type *get(Type *SrcTy);
|
|
|
|
|
|
|
|
FunctionType *get(FunctionType *T) {return cast<FunctionType>(get((Type*)T));}
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// dump - Dump out the type map for debugging purposes.
|
|
|
|
void dump() const {
|
|
|
|
for (DenseMap<Type*, Type*>::const_iterator
|
|
|
|
I = MappedTypes.begin(), E = MappedTypes.end(); I != E; ++I) {
|
|
|
|
dbgs() << "TypeMap: ";
|
|
|
|
I->first->dump();
|
|
|
|
dbgs() << " => ";
|
|
|
|
I->second->dump();
|
|
|
|
dbgs() << '\n';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
private:
|
|
|
|
Type *getImpl(Type *T);
|
|
|
|
/// remapType - Implement the ValueMapTypeRemapper interface.
|
|
|
|
Type *remapType(Type *SrcTy) {
|
|
|
|
return get(SrcTy);
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
bool areTypesIsomorphic(Type *DstTy, Type *SrcTy);
|
|
|
|
};
|
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
void TypeMapTy::addTypeMapping(Type *DstTy, Type *SrcTy) {
|
|
|
|
Type *&Entry = MappedTypes[SrcTy];
|
|
|
|
if (Entry) return;
|
|
|
|
|
|
|
|
if (DstTy == SrcTy) {
|
|
|
|
Entry = DstTy;
|
|
|
|
return;
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Check to see if these types are recursively isomorphic and establish a
|
|
|
|
// mapping between them if so.
|
2012-02-28 12:01:21 +08:00
|
|
|
if (!areTypesIsomorphic(DstTy, SrcTy)) {
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Oops, they aren't isomorphic. Just discard this request by rolling out
|
|
|
|
// any speculative mappings we've established.
|
|
|
|
for (unsigned i = 0, e = SpeculativeTypes.size(); i != e; ++i)
|
|
|
|
MappedTypes.erase(SpeculativeTypes[i]);
|
2012-02-28 12:01:21 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
SpeculativeTypes.clear();
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// areTypesIsomorphic - Recursively walk this pair of types, returning true
|
|
|
|
/// if they are isomorphic, false if they are not.
|
|
|
|
bool TypeMapTy::areTypesIsomorphic(Type *DstTy, Type *SrcTy) {
|
|
|
|
// Two types with differing kinds are clearly not isomorphic.
|
|
|
|
if (DstTy->getTypeID() != SrcTy->getTypeID()) return false;
|
|
|
|
|
|
|
|
// If we have an entry in the MappedTypes table, then we have our answer.
|
|
|
|
Type *&Entry = MappedTypes[SrcTy];
|
|
|
|
if (Entry)
|
|
|
|
return Entry == DstTy;
|
|
|
|
|
|
|
|
// Two identical types are clearly isomorphic. Remember this
|
|
|
|
// non-speculatively.
|
|
|
|
if (DstTy == SrcTy) {
|
|
|
|
Entry = DstTy;
|
2008-06-17 04:03:01 +08:00
|
|
|
return true;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Okay, we have two types with identical kinds that we haven't seen before.
|
|
|
|
|
|
|
|
// If this is an opaque struct type, special case it.
|
|
|
|
if (StructType *SSTy = dyn_cast<StructType>(SrcTy)) {
|
|
|
|
// Mapping an opaque type to any struct, just keep the dest struct.
|
|
|
|
if (SSTy->isOpaque()) {
|
|
|
|
Entry = DstTy;
|
|
|
|
SpeculativeTypes.push_back(SrcTy);
|
2008-06-17 02:27:53 +08:00
|
|
|
return true;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
2011-12-20 08:03:52 +08:00
|
|
|
// Mapping a non-opaque source type to an opaque dest. If this is the first
|
|
|
|
// type that we're mapping onto this destination type then we succeed. Keep
|
|
|
|
// the dest, but fill it in later. This doesn't need to be speculative. If
|
|
|
|
// this is the second (different) type that we're trying to map onto the
|
|
|
|
// same opaque type then we fail.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (cast<StructType>(DstTy)->isOpaque()) {
|
2011-12-20 08:03:52 +08:00
|
|
|
// We can only map one source type onto the opaque destination type.
|
|
|
|
if (!DstResolvedOpaqueTypes.insert(cast<StructType>(DstTy)))
|
|
|
|
return false;
|
|
|
|
SrcDefinitionsToResolve.push_back(SSTy);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
Entry = DstTy;
|
|
|
|
return true;
|
2008-06-17 05:17:12 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// If the number of subtypes disagree between the two types, then we fail.
|
|
|
|
if (SrcTy->getNumContainedTypes() != DstTy->getNumContainedTypes())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Fail if any of the extra properties (e.g. array size) of the type disagree.
|
|
|
|
if (isa<IntegerType>(DstTy))
|
|
|
|
return false; // bitwidth disagrees.
|
|
|
|
if (PointerType *PT = dyn_cast<PointerType>(DstTy)) {
|
|
|
|
if (PT->getAddressSpace() != cast<PointerType>(SrcTy)->getAddressSpace())
|
|
|
|
return false;
|
2011-12-21 07:14:57 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
} else if (FunctionType *FT = dyn_cast<FunctionType>(DstTy)) {
|
|
|
|
if (FT->isVarArg() != cast<FunctionType>(SrcTy)->isVarArg())
|
|
|
|
return false;
|
|
|
|
} else if (StructType *DSTy = dyn_cast<StructType>(DstTy)) {
|
|
|
|
StructType *SSTy = cast<StructType>(SrcTy);
|
2011-08-13 02:07:26 +08:00
|
|
|
if (DSTy->isLiteral() != SSTy->isLiteral() ||
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
DSTy->isPacked() != SSTy->isPacked())
|
|
|
|
return false;
|
|
|
|
} else if (ArrayType *DATy = dyn_cast<ArrayType>(DstTy)) {
|
|
|
|
if (DATy->getNumElements() != cast<ArrayType>(SrcTy)->getNumElements())
|
|
|
|
return false;
|
|
|
|
} else if (VectorType *DVTy = dyn_cast<VectorType>(DstTy)) {
|
|
|
|
if (DVTy->getNumElements() != cast<ArrayType>(SrcTy)->getNumElements())
|
|
|
|
return false;
|
2008-06-17 02:27:53 +08:00
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Otherwise, we speculate that these two types will line up and recursively
|
|
|
|
// check the subelements.
|
|
|
|
Entry = DstTy;
|
|
|
|
SpeculativeTypes.push_back(SrcTy);
|
|
|
|
|
2012-02-28 12:01:21 +08:00
|
|
|
for (unsigned i = 0, e = SrcTy->getNumContainedTypes(); i != e; ++i)
|
|
|
|
if (!areTypesIsomorphic(DstTy->getContainedType(i),
|
|
|
|
SrcTy->getContainedType(i)))
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// If everything seems to have lined up, then everything is great.
|
|
|
|
return true;
|
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// linkDefinedTypeBodies - Produce a body for an opaque type in the dest
|
|
|
|
/// module from a type definition in the source module.
|
|
|
|
void TypeMapTy::linkDefinedTypeBodies() {
|
|
|
|
SmallVector<Type*, 16> Elements;
|
|
|
|
SmallString<16> TmpName;
|
|
|
|
|
|
|
|
// Note that processing entries in this loop (calling 'get') can add new
|
2011-12-20 08:03:52 +08:00
|
|
|
// entries to the SrcDefinitionsToResolve vector.
|
|
|
|
while (!SrcDefinitionsToResolve.empty()) {
|
|
|
|
StructType *SrcSTy = SrcDefinitionsToResolve.pop_back_val();
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
StructType *DstSTy = cast<StructType>(MappedTypes[SrcSTy]);
|
|
|
|
|
|
|
|
// TypeMap is a many-to-one mapping, if there were multiple types that
|
|
|
|
// provide a body for DstSTy then previous iterations of this loop may have
|
|
|
|
// already handled it. Just ignore this case.
|
|
|
|
if (!DstSTy->isOpaque()) continue;
|
|
|
|
assert(!SrcSTy->isOpaque() && "Not resolving a definition?");
|
|
|
|
|
|
|
|
// Map the body of the source type over to a new body for the dest type.
|
|
|
|
Elements.resize(SrcSTy->getNumElements());
|
|
|
|
for (unsigned i = 0, e = Elements.size(); i != e; ++i)
|
|
|
|
Elements[i] = getImpl(SrcSTy->getElementType(i));
|
|
|
|
|
|
|
|
DstSTy->setBody(Elements, SrcSTy->isPacked());
|
|
|
|
|
|
|
|
// If DstSTy has no name or has a longer name than STy, then viciously steal
|
|
|
|
// STy's name.
|
|
|
|
if (!SrcSTy->hasName()) continue;
|
|
|
|
StringRef SrcName = SrcSTy->getName();
|
|
|
|
|
|
|
|
if (!DstSTy->hasName() || DstSTy->getName().size() > SrcName.size()) {
|
|
|
|
TmpName.insert(TmpName.end(), SrcName.begin(), SrcName.end());
|
|
|
|
SrcSTy->setName("");
|
|
|
|
DstSTy->setName(TmpName.str());
|
|
|
|
TmpName.clear();
|
|
|
|
}
|
2005-04-22 06:55:34 +08:00
|
|
|
}
|
2011-12-20 08:03:52 +08:00
|
|
|
|
|
|
|
DstResolvedOpaqueTypes.clear();
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// get - Return the mapped type to use for the specified input type from the
|
|
|
|
/// source module.
|
|
|
|
Type *TypeMapTy::get(Type *Ty) {
|
|
|
|
Type *Result = getImpl(Ty);
|
|
|
|
|
|
|
|
// If this caused a reference to any struct type, resolve it before returning.
|
2011-12-20 08:03:52 +08:00
|
|
|
if (!SrcDefinitionsToResolve.empty())
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
linkDefinedTypeBodies();
|
|
|
|
return Result;
|
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// getImpl - This is the recursive version of get().
|
|
|
|
Type *TypeMapTy::getImpl(Type *Ty) {
|
|
|
|
// If we already have an entry for this type, return it.
|
|
|
|
Type **Entry = &MappedTypes[Ty];
|
|
|
|
if (*Entry) return *Entry;
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// If this is not a named struct type, then just map all of the elements and
|
|
|
|
// then rebuild the type from inside out.
|
2011-08-13 02:07:26 +08:00
|
|
|
if (!isa<StructType>(Ty) || cast<StructType>(Ty)->isLiteral()) {
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// If there are no element types to map, then the type is itself. This is
|
|
|
|
// true for the anonymous {} struct, things like 'float', integers, etc.
|
|
|
|
if (Ty->getNumContainedTypes() == 0)
|
|
|
|
return *Entry = Ty;
|
|
|
|
|
|
|
|
// Remap all of the elements, keeping track of whether any of them change.
|
|
|
|
bool AnyChange = false;
|
|
|
|
SmallVector<Type*, 4> ElementTypes;
|
|
|
|
ElementTypes.resize(Ty->getNumContainedTypes());
|
|
|
|
for (unsigned i = 0, e = Ty->getNumContainedTypes(); i != e; ++i) {
|
|
|
|
ElementTypes[i] = getImpl(Ty->getContainedType(i));
|
|
|
|
AnyChange |= ElementTypes[i] != Ty->getContainedType(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we found our type while recursively processing stuff, just use it.
|
|
|
|
Entry = &MappedTypes[Ty];
|
|
|
|
if (*Entry) return *Entry;
|
|
|
|
|
|
|
|
// If all of the element types mapped directly over, then the type is usable
|
|
|
|
// as-is.
|
|
|
|
if (!AnyChange)
|
|
|
|
return *Entry = Ty;
|
|
|
|
|
|
|
|
// Otherwise, rebuild a modified type.
|
|
|
|
switch (Ty->getTypeID()) {
|
2012-02-07 13:05:23 +08:00
|
|
|
default: llvm_unreachable("unknown derived type to remap");
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
case Type::ArrayTyID:
|
|
|
|
return *Entry = ArrayType::get(ElementTypes[0],
|
|
|
|
cast<ArrayType>(Ty)->getNumElements());
|
|
|
|
case Type::VectorTyID:
|
|
|
|
return *Entry = VectorType::get(ElementTypes[0],
|
|
|
|
cast<VectorType>(Ty)->getNumElements());
|
|
|
|
case Type::PointerTyID:
|
|
|
|
return *Entry = PointerType::get(ElementTypes[0],
|
|
|
|
cast<PointerType>(Ty)->getAddressSpace());
|
|
|
|
case Type::FunctionTyID:
|
|
|
|
return *Entry = FunctionType::get(ElementTypes[0],
|
2011-07-18 20:00:32 +08:00
|
|
|
makeArrayRef(ElementTypes).slice(1),
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
cast<FunctionType>(Ty)->isVarArg());
|
|
|
|
case Type::StructTyID:
|
|
|
|
// Note that this is only reached for anonymous structs.
|
|
|
|
return *Entry = StructType::get(Ty->getContext(), ElementTypes,
|
|
|
|
cast<StructType>(Ty)->isPacked());
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Otherwise, this is an unmapped named struct. If the struct can be directly
|
|
|
|
// mapped over, just use it as-is. This happens in a case when the linked-in
|
|
|
|
// module has something like:
|
|
|
|
// %T = type {%T*, i32}
|
|
|
|
// @GV = global %T* null
|
|
|
|
// where T does not exist at all in the destination module.
|
|
|
|
//
|
|
|
|
// The other case we watch for is when the type is not in the destination
|
|
|
|
// module, but that it has to be rebuilt because it refers to something that
|
|
|
|
// is already mapped. For example, if the destination module has:
|
|
|
|
// %A = type { i32 }
|
|
|
|
// and the source module has something like
|
|
|
|
// %A' = type { i32 }
|
|
|
|
// %B = type { %A'* }
|
|
|
|
// @GV = global %B* null
|
|
|
|
// then we want to create a new type: "%B = type { %A*}" and have it take the
|
|
|
|
// pristine "%B" name from the source module.
|
|
|
|
//
|
|
|
|
// To determine which case this is, we have to recursively walk the type graph
|
|
|
|
// speculating that we'll be able to reuse it unmodified. Only if this is
|
|
|
|
// safe would we map the entire thing over. Because this is an optimization,
|
|
|
|
// and is not required for the prettiness of the linked module, we just skip
|
|
|
|
// it and always rebuild a type here.
|
|
|
|
StructType *STy = cast<StructType>(Ty);
|
|
|
|
|
|
|
|
// If the type is opaque, we can just use it directly.
|
|
|
|
if (STy->isOpaque())
|
|
|
|
return *Entry = STy;
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Otherwise we create a new type and resolve its body later. This will be
|
|
|
|
// resolved by the top level of get().
|
2011-12-20 08:03:52 +08:00
|
|
|
SrcDefinitionsToResolve.push_back(STy);
|
|
|
|
StructType *DTy = StructType::create(STy->getContext());
|
|
|
|
DstResolvedOpaqueTypes.insert(DTy);
|
|
|
|
return *Entry = DTy;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// ModuleLinker implementation.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
namespace {
|
|
|
|
/// ModuleLinker - This is an implementation class for the LinkModules
|
|
|
|
/// function, which is the entrypoint for this file.
|
|
|
|
class ModuleLinker {
|
|
|
|
Module *DstM, *SrcM;
|
|
|
|
|
|
|
|
TypeMapTy TypeMap;
|
|
|
|
|
|
|
|
/// ValueMap - Mapping of values from what they used to be in Src, to what
|
|
|
|
/// they are now in DstM. ValueToValueMapTy is a ValueMap, which involves
|
|
|
|
/// some overhead due to the use of Value handles which the Linker doesn't
|
|
|
|
/// actually need, but this allows us to reuse the ValueMapper code.
|
|
|
|
ValueToValueMapTy ValueMap;
|
|
|
|
|
|
|
|
struct AppendingVarInfo {
|
|
|
|
GlobalVariable *NewGV; // New aggregate global in dest module.
|
|
|
|
Constant *DstInit; // Old initializer from dest module.
|
|
|
|
Constant *SrcInit; // Old initializer from src module.
|
|
|
|
};
|
|
|
|
|
|
|
|
std::vector<AppendingVarInfo> AppendingVars;
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
unsigned Mode; // Mode to treat source module.
|
|
|
|
|
|
|
|
// Set of items not to link in from source.
|
|
|
|
SmallPtrSet<const Value*, 16> DoNotLinkFromSource;
|
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// Vector of functions to lazily link in.
|
|
|
|
std::vector<Function*> LazilyLinkFunctions;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
public:
|
|
|
|
std::string ErrorMsg;
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
ModuleLinker(Module *dstM, Module *srcM, unsigned mode)
|
|
|
|
: DstM(dstM), SrcM(srcM), Mode(mode) { }
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
bool run();
|
|
|
|
|
|
|
|
private:
|
|
|
|
/// emitError - Helper method for setting a message and returning an error
|
|
|
|
/// code.
|
|
|
|
bool emitError(const Twine &Message) {
|
|
|
|
ErrorMsg = Message.str();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getLinkageResult - This analyzes the two global values and determines
|
|
|
|
/// what the result will look like in the destination module.
|
|
|
|
bool getLinkageResult(GlobalValue *Dest, const GlobalValue *Src,
|
2012-01-06 07:02:01 +08:00
|
|
|
GlobalValue::LinkageTypes <,
|
|
|
|
GlobalValue::VisibilityTypes &Vis,
|
|
|
|
bool &LinkFromSrc);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
/// getLinkedToGlobal - Given a global in the source module, return the
|
|
|
|
/// global in the destination module that is being linked to, if any.
|
|
|
|
GlobalValue *getLinkedToGlobal(GlobalValue *SrcGV) {
|
|
|
|
// If the source has no name it can't link. If it has local linkage,
|
|
|
|
// there is no name match-up going on.
|
|
|
|
if (!SrcGV->hasName() || SrcGV->hasLocalLinkage())
|
|
|
|
return 0;
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Otherwise see if we have a match in the destination module's symtab.
|
|
|
|
GlobalValue *DGV = DstM->getNamedValue(SrcGV->getName());
|
|
|
|
if (DGV == 0) return 0;
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// If we found a global with the same name in the dest module, but it has
|
|
|
|
// internal linkage, we are really not doing any linkage here.
|
|
|
|
if (DGV->hasLocalLinkage())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// Otherwise, we do in fact link to the destination global.
|
|
|
|
return DGV;
|
|
|
|
}
|
|
|
|
|
|
|
|
void computeTypeMapping();
|
2012-02-11 19:38:06 +08:00
|
|
|
bool categorizeModuleFlagNodes(const NamedMDNode *ModFlags,
|
|
|
|
DenseMap<MDString*, MDNode*> &ErrorNode,
|
|
|
|
DenseMap<MDString*, MDNode*> &WarningNode,
|
|
|
|
DenseMap<MDString*, MDNode*> &OverrideNode,
|
|
|
|
DenseMap<MDString*,
|
|
|
|
SmallSetVector<MDNode*, 8> > &RequireNodes,
|
|
|
|
SmallSetVector<MDString*, 16> &SeenIDs);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
bool linkAppendingVarProto(GlobalVariable *DstGV, GlobalVariable *SrcGV);
|
|
|
|
bool linkGlobalProto(GlobalVariable *SrcGV);
|
|
|
|
bool linkFunctionProto(Function *SrcF);
|
|
|
|
bool linkAliasProto(GlobalAlias *SrcA);
|
2012-02-11 19:38:06 +08:00
|
|
|
bool linkModuleFlagsMetadata();
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
void linkAppendingVarInit(const AppendingVarInfo &AVI);
|
|
|
|
void linkGlobalInits();
|
|
|
|
void linkFunctionBody(Function *Dst, Function *Src);
|
|
|
|
void linkAliasBodies();
|
|
|
|
void linkNamedMDNodes();
|
|
|
|
};
|
2012-02-28 12:01:21 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// forceRenaming - The LLVM SymbolTable class autorenames globals that conflict
|
2007-02-04 12:29:21 +08:00
|
|
|
/// in the symbol table. This is good for all clients except for us. Go
|
|
|
|
/// through the trouble to force this back.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
static void forceRenaming(GlobalValue *GV, StringRef Name) {
|
|
|
|
// If the global doesn't force its name or if it already has the right name,
|
|
|
|
// there is nothing for us to do.
|
|
|
|
if (GV->hasLocalLinkage() || GV->getName() == Name)
|
|
|
|
return;
|
|
|
|
|
|
|
|
Module *M = GV->getParent();
|
2004-11-13 04:37:43 +08:00
|
|
|
|
|
|
|
// If there is a conflict, rename the conflict.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (GlobalValue *ConflictGV = M->getNamedValue(Name)) {
|
2007-02-11 08:39:38 +08:00
|
|
|
GV->takeName(ConflictGV);
|
|
|
|
ConflictGV->setName(Name); // This will cause ConflictGV to get renamed
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
assert(ConflictGV->getName() != Name && "forceRenaming didn't work");
|
2007-02-11 08:39:38 +08:00
|
|
|
} else {
|
|
|
|
GV->setName(Name); // Force the name back
|
2007-02-06 04:47:22 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// copyGVAttributes - copy additional attributes (those not needed to construct
|
2009-03-03 15:22:23 +08:00
|
|
|
/// a GlobalValue) from the SrcGV to the DestGV.
|
2012-03-23 04:28:27 +08:00
|
|
|
static void copyGVAttributes(GlobalValue *DestGV, const GlobalValue *SrcGV) {
|
2008-05-27 03:58:59 +08:00
|
|
|
// Use the maximum alignment, rather than just copying the alignment of SrcGV.
|
|
|
|
unsigned Alignment = std::max(DestGV->getAlignment(), SrcGV->getAlignment());
|
|
|
|
DestGV->copyAttributesFrom(SrcGV);
|
|
|
|
DestGV->setAlignment(Alignment);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
forceRenaming(DestGV, SrcGV->getName());
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2012-01-06 07:02:01 +08:00
|
|
|
static bool isLessConstraining(GlobalValue::VisibilityTypes a,
|
|
|
|
GlobalValue::VisibilityTypes b) {
|
|
|
|
if (a == GlobalValue::HiddenVisibility)
|
|
|
|
return false;
|
|
|
|
if (b == GlobalValue::HiddenVisibility)
|
|
|
|
return true;
|
|
|
|
if (a == GlobalValue::ProtectedVisibility)
|
|
|
|
return false;
|
|
|
|
if (b == GlobalValue::ProtectedVisibility)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// getLinkageResult - This analyzes the two global values and determines what
|
2004-12-04 06:18:41 +08:00
|
|
|
/// the result will look like in the destination module. In particular, it
|
2012-01-06 07:02:01 +08:00
|
|
|
/// computes the resultant linkage type and visibility, computes whether the
|
|
|
|
/// global in the source should be copied over to the destination (replacing
|
|
|
|
/// the existing one), and computes whether this linkage is an error or not.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
bool ModuleLinker::getLinkageResult(GlobalValue *Dest, const GlobalValue *Src,
|
2012-01-06 07:02:01 +08:00
|
|
|
GlobalValue::LinkageTypes <,
|
|
|
|
GlobalValue::VisibilityTypes &Vis,
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
bool &LinkFromSrc) {
|
|
|
|
assert(Dest && "Must have two globals being queried");
|
|
|
|
assert(!Src->hasLocalLinkage() &&
|
2004-12-04 06:18:41 +08:00
|
|
|
"If Src has internal linkage, Dest shouldn't be set!");
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
2011-10-31 01:46:34 +08:00
|
|
|
bool SrcIsDeclaration = Src->isDeclaration() && !Src->isMaterializable();
|
2011-07-15 04:23:05 +08:00
|
|
|
bool DestIsDeclaration = Dest->isDeclaration();
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
if (SrcIsDeclaration) {
|
2008-03-11 06:33:22 +08:00
|
|
|
// If Src is external or if both Src & Dest are external.. Just link the
|
2004-12-04 06:18:41 +08:00
|
|
|
// external globals, we aren't adding anything.
|
2006-09-15 02:23:27 +08:00
|
|
|
if (Src->hasDLLImportLinkage()) {
|
2006-12-01 08:25:12 +08:00
|
|
|
// If one of GVs has DLLImport linkage, result should be dllimport'ed.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (DestIsDeclaration) {
|
2006-09-15 02:23:27 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
LT = Src->getLinkage();
|
2009-03-03 15:22:23 +08:00
|
|
|
}
|
2006-12-16 01:35:32 +08:00
|
|
|
} else if (Dest->hasExternalWeakLinkage()) {
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
2009-03-07 23:45:40 +08:00
|
|
|
// If the Dest is weak, use the source linkage.
|
2006-12-16 01:35:32 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
LT = Src->getLinkage();
|
2006-09-15 02:23:27 +08:00
|
|
|
} else {
|
|
|
|
LinkFromSrc = false;
|
|
|
|
LT = Dest->getLinkage();
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
} else if (DestIsDeclaration && !Dest->hasDLLImportLinkage()) {
|
2004-12-04 06:18:41 +08:00
|
|
|
// If Dest is external but Src is not:
|
|
|
|
LinkFromSrc = true;
|
|
|
|
LT = Src->getLinkage();
|
2009-03-08 21:35:23 +08:00
|
|
|
} else if (Src->isWeakForLinker()) {
|
2008-05-15 04:12:51 +08:00
|
|
|
// At this point we know that Dest has LinkOnce, External*, Weak, Common,
|
|
|
|
// or DLL* linkage.
|
2009-04-13 13:44:34 +08:00
|
|
|
if (Dest->hasExternalWeakLinkage() ||
|
|
|
|
Dest->hasAvailableExternallyLinkage() ||
|
|
|
|
(Dest->hasLinkOnceLinkage() &&
|
|
|
|
(Src->hasWeakLinkage() || Src->hasCommonLinkage()))) {
|
2004-12-04 06:18:41 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
LT = Src->getLinkage();
|
|
|
|
} else {
|
|
|
|
LinkFromSrc = false;
|
|
|
|
LT = Dest->getLinkage();
|
|
|
|
}
|
2009-03-08 21:35:23 +08:00
|
|
|
} else if (Dest->isWeakForLinker()) {
|
2006-12-01 08:25:12 +08:00
|
|
|
// At this point we know that Src has External* or DLL* linkage.
|
|
|
|
if (Src->hasExternalWeakLinkage()) {
|
|
|
|
LinkFromSrc = false;
|
|
|
|
LT = Dest->getLinkage();
|
|
|
|
} else {
|
|
|
|
LinkFromSrc = true;
|
|
|
|
LT = GlobalValue::ExternalLinkage;
|
|
|
|
}
|
2004-12-04 06:18:41 +08:00
|
|
|
} else {
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
assert((Dest->hasExternalLinkage() || Dest->hasDLLImportLinkage() ||
|
|
|
|
Dest->hasDLLExportLinkage() || Dest->hasExternalWeakLinkage()) &&
|
|
|
|
(Src->hasExternalLinkage() || Src->hasDLLImportLinkage() ||
|
|
|
|
Src->hasDLLExportLinkage() || Src->hasExternalWeakLinkage()) &&
|
2004-12-04 06:18:41 +08:00
|
|
|
"Unexpected linkage type!");
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return emitError("Linking globals named '" + Src->getName() +
|
2004-12-04 06:18:41 +08:00
|
|
|
"': symbol multiply defined!");
|
|
|
|
}
|
2007-04-30 04:56:48 +08:00
|
|
|
|
2012-01-06 07:02:01 +08:00
|
|
|
// Compute the visibility. We follow the rules in the System V Application
|
|
|
|
// Binary Interface.
|
|
|
|
Vis = isLessConstraining(Src->getVisibility(), Dest->getVisibility()) ?
|
|
|
|
Dest->getVisibility() : Src->getVisibility();
|
2004-12-04 06:18:41 +08:00
|
|
|
return false;
|
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// computeTypeMapping - Loop over all of the linked values to compute type
|
|
|
|
/// mappings. For example, if we link "extern Foo *x" and "Foo *x = NULL", then
|
|
|
|
/// we have two struct types 'Foo' but one got renamed when the module was
|
|
|
|
/// loaded into the same LLVMContext.
|
|
|
|
void ModuleLinker::computeTypeMapping() {
|
|
|
|
// Incorporate globals.
|
|
|
|
for (Module::global_iterator I = SrcM->global_begin(),
|
|
|
|
E = SrcM->global_end(); I != E; ++I) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(I);
|
|
|
|
if (DGV == 0) continue;
|
|
|
|
|
|
|
|
if (!DGV->hasAppendingLinkage() || !I->hasAppendingLinkage()) {
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), I->getType());
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unify the element type of appending arrays.
|
|
|
|
ArrayType *DAT = cast<ArrayType>(DGV->getType()->getElementType());
|
|
|
|
ArrayType *SAT = cast<ArrayType>(I->getType()->getElementType());
|
|
|
|
TypeMap.addTypeMapping(DAT->getElementType(), SAT->getElementType());
|
2009-08-12 02:01:24 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// Incorporate functions.
|
|
|
|
for (Module::iterator I = SrcM->begin(), E = SrcM->end(); I != E; ++I) {
|
|
|
|
if (GlobalValue *DGV = getLinkedToGlobal(I))
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), I->getType());
|
|
|
|
}
|
2012-02-28 06:34:19 +08:00
|
|
|
|
2012-02-28 12:01:21 +08:00
|
|
|
// Incorporate types by name, scanning all the types in the source module.
|
|
|
|
// At this point, the destination module may have a type "%foo = { i32 }" for
|
2012-02-28 07:48:30 +08:00
|
|
|
// example. When the source module got loaded into the same LLVMContext, if
|
|
|
|
// it had the same type, it would have been renamed to "%foo.42 = { i32 }".
|
2012-08-03 08:30:35 +08:00
|
|
|
TypeFinder SrcStructTypes;
|
|
|
|
SrcStructTypes.run(*SrcM, true);
|
2012-02-28 07:48:30 +08:00
|
|
|
SmallPtrSet<StructType*, 32> SrcStructTypesSet(SrcStructTypes.begin(),
|
|
|
|
SrcStructTypes.end());
|
It's possible for two types, which are isomorphic, to be added to the
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
llvm-svn: 153351
2012-03-24 07:17:38 +08:00
|
|
|
|
2012-08-03 08:30:35 +08:00
|
|
|
TypeFinder DstStructTypes;
|
|
|
|
DstStructTypes.run(*DstM, true);
|
It's possible for two types, which are isomorphic, to be added to the
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
llvm-svn: 153351
2012-03-24 07:17:38 +08:00
|
|
|
SmallPtrSet<StructType*, 32> DstStructTypesSet(DstStructTypes.begin(),
|
|
|
|
DstStructTypes.end());
|
|
|
|
|
2012-02-28 07:48:30 +08:00
|
|
|
for (unsigned i = 0, e = SrcStructTypes.size(); i != e; ++i) {
|
|
|
|
StructType *ST = SrcStructTypes[i];
|
|
|
|
if (!ST->hasName()) continue;
|
|
|
|
|
|
|
|
// Check to see if there is a dot in the name followed by a digit.
|
2012-02-28 12:01:21 +08:00
|
|
|
size_t DotPos = ST->getName().rfind('.');
|
|
|
|
if (DotPos == 0 || DotPos == StringRef::npos ||
|
|
|
|
ST->getName().back() == '.' || !isdigit(ST->getName()[DotPos+1]))
|
|
|
|
continue;
|
2012-02-28 07:48:30 +08:00
|
|
|
|
|
|
|
// Check to see if the destination module has a struct with the prefix name.
|
2012-02-28 12:01:21 +08:00
|
|
|
if (StructType *DST = DstM->getTypeByName(ST->getName().substr(0, DotPos)))
|
It's possible for two types, which are isomorphic, to be added to the
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
llvm-svn: 153351
2012-03-24 07:17:38 +08:00
|
|
|
// Don't use it if this actually came from the source module. They're in
|
|
|
|
// the same LLVMContext after all. Also don't use it unless the type is
|
|
|
|
// actually used in the destination module. This can happen in situations
|
|
|
|
// like this:
|
|
|
|
//
|
|
|
|
// Module A Module B
|
|
|
|
// -------- --------
|
|
|
|
// %Z = type { %A } %B = type { %C.1 }
|
|
|
|
// %A = type { %B.1, [7 x i8] } %C.1 = type { i8* }
|
|
|
|
// %B.1 = type { %C } %A.2 = type { %B.3, [5 x i8] }
|
|
|
|
// %C = type { i8* } %B.3 = type { %C.1 }
|
|
|
|
//
|
|
|
|
// When we link Module B with Module A, the '%B' in Module B is
|
|
|
|
// used. However, that would then use '%C.1'. But when we process '%C.1',
|
|
|
|
// we prefer to take the '%C' version. So we are then left with both
|
|
|
|
// '%C.1' and '%C' being used for the same types. This leads to some
|
|
|
|
// variables using one type and some using the other.
|
|
|
|
if (!SrcStructTypesSet.count(DST) && DstStructTypesSet.count(DST))
|
2012-02-28 07:48:30 +08:00
|
|
|
TypeMap.addTypeMapping(DST, ST);
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Don't bother incorporating aliases, they aren't generally typed well.
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Now that we have discovered all of the type equivalences, get a body for
|
|
|
|
// any 'opaque' types in the dest module that are now resolved.
|
|
|
|
TypeMap.linkDefinedTypeBodies();
|
2009-08-12 02:01:24 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// linkAppendingVarProto - If there were any appending global variables, link
|
|
|
|
/// them together now. Return true on error.
|
|
|
|
bool ModuleLinker::linkAppendingVarProto(GlobalVariable *DstGV,
|
|
|
|
GlobalVariable *SrcGV) {
|
2012-02-28 12:01:21 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!SrcGV->hasAppendingLinkage() || !DstGV->hasAppendingLinkage())
|
|
|
|
return emitError("Linking globals named '" + SrcGV->getName() +
|
|
|
|
"': can only link appending global with another appending global!");
|
|
|
|
|
|
|
|
ArrayType *DstTy = cast<ArrayType>(DstGV->getType()->getElementType());
|
|
|
|
ArrayType *SrcTy =
|
|
|
|
cast<ArrayType>(TypeMap.get(SrcGV->getType()->getElementType()));
|
|
|
|
Type *EltTy = DstTy->getElementType();
|
|
|
|
|
|
|
|
// Check to see that they two arrays agree on type.
|
|
|
|
if (EltTy != SrcTy->getElementType())
|
|
|
|
return emitError("Appending variables with different element types!");
|
|
|
|
if (DstGV->isConstant() != SrcGV->isConstant())
|
|
|
|
return emitError("Appending variables linked with different const'ness!");
|
|
|
|
|
|
|
|
if (DstGV->getAlignment() != SrcGV->getAlignment())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different alignment need to be linked!");
|
|
|
|
|
|
|
|
if (DstGV->getVisibility() != SrcGV->getVisibility())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different visibility need to be linked!");
|
|
|
|
|
|
|
|
if (DstGV->getSection() != SrcGV->getSection())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different section name need to be linked!");
|
|
|
|
|
|
|
|
uint64_t NewSize = DstTy->getNumElements() + SrcTy->getNumElements();
|
|
|
|
ArrayType *NewType = ArrayType::get(EltTy, NewSize);
|
|
|
|
|
|
|
|
// Create the new global variable.
|
|
|
|
GlobalVariable *NG =
|
|
|
|
new GlobalVariable(*DstGV->getParent(), NewType, SrcGV->isConstant(),
|
|
|
|
DstGV->getLinkage(), /*init*/0, /*name*/"", DstGV,
|
2012-06-23 19:37:03 +08:00
|
|
|
DstGV->getThreadLocalMode(),
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
DstGV->getType()->getAddressSpace());
|
|
|
|
|
|
|
|
// Propagate alignment, visibility and section info.
|
2012-03-23 04:28:27 +08:00
|
|
|
copyGVAttributes(NG, DstGV);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
AppendingVarInfo AVI;
|
|
|
|
AVI.NewGV = NG;
|
|
|
|
AVI.DstInit = DstGV->getInitializer();
|
|
|
|
AVI.SrcInit = SrcGV->getInitializer();
|
|
|
|
AppendingVars.push_back(AVI);
|
|
|
|
|
|
|
|
// Replace any uses of the two global variables with uses of the new
|
|
|
|
// global.
|
|
|
|
ValueMap[SrcGV] = ConstantExpr::getBitCast(NG, TypeMap.get(SrcGV->getType()));
|
|
|
|
|
|
|
|
DstGV->replaceAllUsesWith(ConstantExpr::getBitCast(NG, DstGV->getType()));
|
|
|
|
DstGV->eraseFromParent();
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Track the source variable so we don't try to link it.
|
|
|
|
DoNotLinkFromSource.insert(SrcGV);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// linkGlobalProto - Loop through the global variables in the src module and
|
|
|
|
/// merge them into the dest module.
|
|
|
|
bool ModuleLinker::linkGlobalProto(GlobalVariable *SGV) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(SGV);
|
2012-01-06 07:02:01 +08:00
|
|
|
llvm::Optional<GlobalValue::VisibilityTypes> NewVisibility;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
if (DGV) {
|
|
|
|
// Concatenation of appending linkage variables is magic and handled later.
|
|
|
|
if (DGV->hasAppendingLinkage() || SGV->hasAppendingLinkage())
|
|
|
|
return linkAppendingVarProto(cast<GlobalVariable>(DGV), SGV);
|
|
|
|
|
|
|
|
// Determine whether linkage of these two globals follows the source
|
|
|
|
// module's definition or the destination module's definition.
|
2006-11-09 13:18:12 +08:00
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
2012-01-06 07:02:01 +08:00
|
|
|
GlobalValue::VisibilityTypes NV;
|
2006-11-09 13:18:12 +08:00
|
|
|
bool LinkFromSrc = false;
|
2012-01-06 07:02:01 +08:00
|
|
|
if (getLinkageResult(DGV, SGV, NewLinkage, NV, LinkFromSrc))
|
2004-12-04 06:18:41 +08:00
|
|
|
return true;
|
2012-01-06 07:02:01 +08:00
|
|
|
NewVisibility = NV;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// If we're not linking from the source, then keep the definition that we
|
|
|
|
// have.
|
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Special case for const propagation.
|
|
|
|
if (GlobalVariable *DGVar = dyn_cast<GlobalVariable>(DGV))
|
|
|
|
if (DGVar->isDeclaration() && SGV->isConstant() && !DGVar->isConstant())
|
|
|
|
DGVar->setConstant(true);
|
|
|
|
|
2012-01-06 07:02:01 +08:00
|
|
|
// Set calculated linkage and visibility.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
DGV->setLinkage(NewLinkage);
|
2012-01-06 07:02:01 +08:00
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
|
2008-07-14 15:23:24 +08:00
|
|
|
// Make sure to remember this mapping.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
ValueMap[SGV] = ConstantExpr::getBitCast(DGV,TypeMap.get(SGV->getType()));
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Track the source global so that we don't attempt to copy it over when
|
|
|
|
// processing global initializers.
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
2008-07-14 15:23:24 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// No linking to be performed or linking from the source: simply create an
|
|
|
|
// identical version of the symbol over in the dest module... the
|
|
|
|
// initializer will be filled in later by LinkGlobalInits.
|
|
|
|
GlobalVariable *NewDGV =
|
|
|
|
new GlobalVariable(*DstM, TypeMap.get(SGV->getType()->getElementType()),
|
|
|
|
SGV->isConstant(), SGV->getLinkage(), /*init*/0,
|
|
|
|
SGV->getName(), /*insertbefore*/0,
|
2012-06-23 19:37:03 +08:00
|
|
|
SGV->getThreadLocalMode(),
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
SGV->getType()->getAddressSpace());
|
|
|
|
// Propagate alignment, visibility and section info.
|
2012-03-23 04:28:27 +08:00
|
|
|
copyGVAttributes(NewDGV, SGV);
|
2012-01-06 07:02:01 +08:00
|
|
|
if (NewVisibility)
|
|
|
|
NewDGV->setVisibility(*NewVisibility);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
if (DGV) {
|
|
|
|
DGV->replaceAllUsesWith(ConstantExpr::getBitCast(NewDGV, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
2008-03-06 06:22:46 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// Make sure to remember this mapping.
|
|
|
|
ValueMap[SGV] = NewDGV;
|
2007-06-29 03:02:54 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// linkFunctionProto - Link the function in the source module into the
|
|
|
|
/// destination module if needed, setting up mapping information.
|
|
|
|
bool ModuleLinker::linkFunctionProto(Function *SF) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(SF);
|
2012-01-06 07:02:01 +08:00
|
|
|
llvm::Optional<GlobalValue::VisibilityTypes> NewVisibility;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (DGV) {
|
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
|
|
|
bool LinkFromSrc = false;
|
2012-01-06 07:02:01 +08:00
|
|
|
GlobalValue::VisibilityTypes NV;
|
|
|
|
if (getLinkageResult(DGV, SF, NewLinkage, NV, LinkFromSrc))
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return true;
|
2012-01-06 07:02:01 +08:00
|
|
|
NewVisibility = NV;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Set calculated linkage
|
|
|
|
DGV->setLinkage(NewLinkage);
|
2012-01-06 07:02:01 +08:00
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Make sure to remember this mapping.
|
|
|
|
ValueMap[SF] = ConstantExpr::getBitCast(DGV, TypeMap.get(SF->getType()));
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Track the function from the source module so we don't attempt to remap
|
|
|
|
// it.
|
|
|
|
DoNotLinkFromSource.insert(SF);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// If there is no linkage to be performed or we are linking from the source,
|
|
|
|
// bring SF over.
|
|
|
|
Function *NewDF = Function::Create(TypeMap.get(SF->getFunctionType()),
|
|
|
|
SF->getLinkage(), SF->getName(), DstM);
|
2012-03-23 04:28:27 +08:00
|
|
|
copyGVAttributes(NewDF, SF);
|
2012-01-06 07:02:01 +08:00
|
|
|
if (NewVisibility)
|
|
|
|
NewDF->setVisibility(*NewVisibility);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
if (DGV) {
|
|
|
|
// Any uses of DF need to change to NewDF, with cast.
|
|
|
|
DGV->replaceAllUsesWith(ConstantExpr::getBitCast(NewDF, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
2011-11-02 08:24:56 +08:00
|
|
|
} else {
|
|
|
|
// Internal, LO_ODR, or LO linkage - stick in set to ignore and lazily link.
|
|
|
|
if (SF->hasLocalLinkage() || SF->hasLinkOnceLinkage() ||
|
|
|
|
SF->hasAvailableExternallyLinkage()) {
|
|
|
|
DoNotLinkFromSource.insert(SF);
|
|
|
|
LazilyLinkFunctions.push_back(SF);
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ValueMap[SF] = NewDF;
|
2004-11-13 04:37:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// LinkAliasProto - Set up prototypes for any aliases that come over from the
|
|
|
|
/// source module.
|
|
|
|
bool ModuleLinker::linkAliasProto(GlobalAlias *SGA) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(SGA);
|
2012-01-06 07:02:01 +08:00
|
|
|
llvm::Optional<GlobalValue::VisibilityTypes> NewVisibility;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (DGV) {
|
2008-07-14 15:23:24 +08:00
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
2012-01-06 07:02:01 +08:00
|
|
|
GlobalValue::VisibilityTypes NV;
|
2008-07-14 15:23:24 +08:00
|
|
|
bool LinkFromSrc = false;
|
2012-01-06 07:02:01 +08:00
|
|
|
if (getLinkageResult(DGV, SGA, NewLinkage, NV, LinkFromSrc))
|
2008-07-14 15:23:24 +08:00
|
|
|
return true;
|
2012-01-06 07:02:01 +08:00
|
|
|
NewVisibility = NV;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Set calculated linkage.
|
|
|
|
DGV->setLinkage(NewLinkage);
|
2012-01-06 07:02:01 +08:00
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Make sure to remember this mapping.
|
|
|
|
ValueMap[SGA] = ConstantExpr::getBitCast(DGV,TypeMap.get(SGA->getType()));
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Track the alias from the source module so we don't attempt to remap it.
|
|
|
|
DoNotLinkFromSource.insert(SGA);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
2008-06-09 15:47:34 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// If there is no linkage to be performed or we're linking from the source,
|
|
|
|
// bring over SGA.
|
|
|
|
GlobalAlias *NewDA = new GlobalAlias(TypeMap.get(SGA->getType()),
|
|
|
|
SGA->getLinkage(), SGA->getName(),
|
|
|
|
/*aliasee*/0, DstM);
|
2012-03-23 04:28:27 +08:00
|
|
|
copyGVAttributes(NewDA, SGA);
|
2012-01-06 07:02:01 +08:00
|
|
|
if (NewVisibility)
|
|
|
|
NewDA->setVisibility(*NewVisibility);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
if (DGV) {
|
|
|
|
// Any uses of DGV need to change to NewDA, with cast.
|
|
|
|
DGV->replaceAllUsesWith(ConstantExpr::getBitCast(NewDA, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
ValueMap[SGA] = NewDA;
|
|
|
|
return false;
|
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
2012-01-24 21:41:11 +08:00
|
|
|
static void getArrayElements(Constant *C, SmallVectorImpl<Constant*> &Dest) {
|
2012-01-25 14:48:06 +08:00
|
|
|
unsigned NumElements = cast<ArrayType>(C->getType())->getNumElements();
|
|
|
|
|
|
|
|
for (unsigned i = 0; i != NumElements; ++i)
|
|
|
|
Dest.push_back(C->getAggregateElement(i));
|
2012-01-24 21:41:11 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
void ModuleLinker::linkAppendingVarInit(const AppendingVarInfo &AVI) {
|
|
|
|
// Merge the initializer.
|
|
|
|
SmallVector<Constant*, 16> Elements;
|
2012-01-24 21:41:11 +08:00
|
|
|
getArrayElements(AVI.DstInit, Elements);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
Constant *SrcInit = MapValue(AVI.SrcInit, ValueMap, RF_None, &TypeMap);
|
2012-01-24 21:41:11 +08:00
|
|
|
getArrayElements(SrcInit, Elements);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
ArrayType *NewType = cast<ArrayType>(AVI.NewGV->getType()->getElementType());
|
|
|
|
AVI.NewGV->setInitializer(ConstantArray::get(NewType, Elements));
|
|
|
|
}
|
2008-07-14 15:23:24 +08:00
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// linkGlobalInits - Update the initializers in the Dest module now that all
|
|
|
|
/// globals that may be referenced are in Dest.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
void ModuleLinker::linkGlobalInits() {
|
|
|
|
// Loop over all of the globals in the src module, mapping them over as we go
|
|
|
|
for (Module::const_global_iterator I = SrcM->global_begin(),
|
|
|
|
E = SrcM->global_end(); I != E; ++I) {
|
2011-10-11 08:24:54 +08:00
|
|
|
|
|
|
|
// Only process initialized GV's or ones not already in dest.
|
|
|
|
if (!I->hasInitializer() || DoNotLinkFromSource.count(I)) continue;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
// Grab destination global variable.
|
|
|
|
GlobalVariable *DGV = cast<GlobalVariable>(ValueMap[I]);
|
|
|
|
// Figure out what the initializer looks like in the dest module.
|
|
|
|
DGV->setInitializer(MapValue(I->getInitializer(), ValueMap,
|
|
|
|
RF_None, &TypeMap));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// linkFunctionBody - Copy the source function over into the dest function and
|
|
|
|
/// fix up references to values. At this point we know that Dest is an external
|
|
|
|
/// function, and that Src is not.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
void ModuleLinker::linkFunctionBody(Function *Dst, Function *Src) {
|
|
|
|
assert(Src && Dst && Dst->isDeclaration() && !Src->isDeclaration());
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2004-11-17 01:12:38 +08:00
|
|
|
// Go through and convert function arguments over, remembering the mapping.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
Function::arg_iterator DI = Dst->arg_begin();
|
2005-03-15 12:54:21 +08:00
|
|
|
for (Function::arg_iterator I = Src->arg_begin(), E = Src->arg_end();
|
2004-11-13 04:37:43 +08:00
|
|
|
I != E; ++I, ++DI) {
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
DI->setName(I->getName()); // Copy the name over.
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Add a mapping to our mapping.
|
2008-03-11 06:36:08 +08:00
|
|
|
ValueMap[I] = DI;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
if (Mode == Linker::DestroySource) {
|
|
|
|
// Splice the body of the source function into the dest function.
|
|
|
|
Dst->getBasicBlockList().splice(Dst->end(), Src->getBasicBlockList());
|
|
|
|
|
|
|
|
// At this point, all of the instructions and values of the function are now
|
|
|
|
// copied over. The only problem is that they are still referencing values in
|
|
|
|
// the Source function as operands. Loop through all of the operands of the
|
|
|
|
// functions and patch them up to point to the local versions.
|
|
|
|
for (Function::iterator BB = Dst->begin(), BE = Dst->end(); BB != BE; ++BB)
|
|
|
|
for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I)
|
|
|
|
RemapInstruction(I, ValueMap, RF_IgnoreMissingEntries, &TypeMap);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
// Clone the body of the function into the dest function.
|
|
|
|
SmallVector<ReturnInst*, 8> Returns; // Ignore returns.
|
2011-12-23 10:18:32 +08:00
|
|
|
CloneFunctionInto(Dst, Src, ValueMap, false, Returns, "", NULL, &TypeMap);
|
2011-10-11 08:24:54 +08:00
|
|
|
}
|
|
|
|
|
2004-11-17 01:12:38 +08:00
|
|
|
// There is no need to map the arguments anymore.
|
2006-06-16 09:24:04 +08:00
|
|
|
for (Function::arg_iterator I = Src->arg_begin(), E = Src->arg_end();
|
|
|
|
I != E; ++I)
|
2007-02-06 04:47:22 +08:00
|
|
|
ValueMap.erase(I);
|
2011-10-11 08:24:54 +08:00
|
|
|
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// linkAliasBodies - Insert all of the aliases in Src into the Dest module.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
void ModuleLinker::linkAliasBodies() {
|
|
|
|
for (Module::alias_iterator I = SrcM->alias_begin(), E = SrcM->alias_end();
|
2011-10-11 08:24:54 +08:00
|
|
|
I != E; ++I) {
|
|
|
|
if (DoNotLinkFromSource.count(I))
|
|
|
|
continue;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (Constant *Aliasee = I->getAliasee()) {
|
|
|
|
GlobalAlias *DA = cast<GlobalAlias>(ValueMap[I]);
|
|
|
|
DA->setAliasee(MapValue(Aliasee, ValueMap, RF_None, &TypeMap));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2011-10-11 08:24:54 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// linkNamedMDNodes - Insert all of the named MDNodes in Src into the Dest
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
/// module.
|
|
|
|
void ModuleLinker::linkNamedMDNodes() {
|
2012-02-11 19:38:06 +08:00
|
|
|
const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
for (Module::const_named_metadata_iterator I = SrcM->named_metadata_begin(),
|
|
|
|
E = SrcM->named_metadata_end(); I != E; ++I) {
|
2012-02-11 19:38:06 +08:00
|
|
|
// Don't link module flags here. Do them separately.
|
|
|
|
if (&*I == SrcModFlags) continue;
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
NamedMDNode *DestNMD = DstM->getOrInsertNamedMetadata(I->getName());
|
|
|
|
// Add Src elements into Dest node.
|
|
|
|
for (unsigned i = 0, e = I->getNumOperands(); i != e; ++i)
|
|
|
|
DestNMD->addOperand(MapValue(I->getOperand(i), ValueMap,
|
|
|
|
RF_None, &TypeMap));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// categorizeModuleFlagNodes - Categorize the module flags according to their
|
|
|
|
/// type: Error, Warning, Override, and Require.
|
2012-02-11 19:38:06 +08:00
|
|
|
bool ModuleLinker::
|
|
|
|
categorizeModuleFlagNodes(const NamedMDNode *ModFlags,
|
|
|
|
DenseMap<MDString*, MDNode*> &ErrorNode,
|
|
|
|
DenseMap<MDString*, MDNode*> &WarningNode,
|
|
|
|
DenseMap<MDString*, MDNode*> &OverrideNode,
|
|
|
|
DenseMap<MDString*,
|
|
|
|
SmallSetVector<MDNode*, 8> > &RequireNodes,
|
|
|
|
SmallSetVector<MDString*, 16> &SeenIDs) {
|
|
|
|
bool HasErr = false;
|
|
|
|
|
|
|
|
for (unsigned I = 0, E = ModFlags->getNumOperands(); I != E; ++I) {
|
|
|
|
MDNode *Op = ModFlags->getOperand(I);
|
|
|
|
assert(Op->getNumOperands() == 3 && "Invalid module flag metadata!");
|
|
|
|
assert(isa<ConstantInt>(Op->getOperand(0)) &&
|
|
|
|
"Module flag's first operand must be an integer!");
|
|
|
|
assert(isa<MDString>(Op->getOperand(1)) &&
|
|
|
|
"Module flag's second operand must be an MDString!");
|
|
|
|
|
|
|
|
ConstantInt *Behavior = cast<ConstantInt>(Op->getOperand(0));
|
|
|
|
MDString *ID = cast<MDString>(Op->getOperand(1));
|
|
|
|
Value *Val = Op->getOperand(2);
|
|
|
|
switch (Behavior->getZExtValue()) {
|
|
|
|
default:
|
|
|
|
assert(false && "Invalid behavior in module flag metadata!");
|
|
|
|
break;
|
|
|
|
case Module::Error: {
|
|
|
|
MDNode *&ErrNode = ErrorNode[ID];
|
|
|
|
if (!ErrNode) ErrNode = Op;
|
|
|
|
if (ErrNode->getOperand(2) != Val)
|
2012-02-14 17:13:54 +08:00
|
|
|
HasErr = emitError("linking module flags '" + ID->getString() +
|
|
|
|
"': IDs have conflicting values");
|
2012-02-11 19:38:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Module::Warning: {
|
|
|
|
MDNode *&WarnNode = WarningNode[ID];
|
|
|
|
if (!WarnNode) WarnNode = Op;
|
|
|
|
if (WarnNode->getOperand(2) != Val)
|
2012-02-14 17:13:54 +08:00
|
|
|
errs() << "WARNING: linking module flags '" << ID->getString()
|
|
|
|
<< "': IDs have conflicting values";
|
2012-02-11 19:38:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Module::Require: RequireNodes[ID].insert(Op); break;
|
|
|
|
case Module::Override: {
|
|
|
|
MDNode *&OvrNode = OverrideNode[ID];
|
|
|
|
if (!OvrNode) OvrNode = Op;
|
|
|
|
if (OvrNode->getOperand(2) != Val)
|
2012-02-14 17:13:54 +08:00
|
|
|
HasErr = emitError("linking module flags '" + ID->getString() +
|
|
|
|
"': IDs have conflicting override values");
|
2012-02-11 19:38:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SeenIDs.insert(ID);
|
|
|
|
}
|
|
|
|
|
|
|
|
return HasErr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// linkModuleFlagsMetadata - Merge the linker flags in Src into the Dest
|
|
|
|
/// module.
|
|
|
|
bool ModuleLinker::linkModuleFlagsMetadata() {
|
|
|
|
const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
|
|
|
|
if (!SrcModFlags) return false;
|
|
|
|
|
|
|
|
NamedMDNode *DstModFlags = DstM->getOrInsertModuleFlagsMetadata();
|
|
|
|
|
|
|
|
// If the destination module doesn't have module flags yet, then just copy
|
|
|
|
// over the source module's flags.
|
|
|
|
if (DstModFlags->getNumOperands() == 0) {
|
|
|
|
for (unsigned I = 0, E = SrcModFlags->getNumOperands(); I != E; ++I)
|
|
|
|
DstModFlags->addOperand(SrcModFlags->getOperand(I));
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool HasErr = false;
|
|
|
|
|
|
|
|
// Otherwise, we have to merge them based on their behaviors. First,
|
|
|
|
// categorize all of the nodes in the modules' module flags. If an error or
|
|
|
|
// warning occurs, then emit the appropriate message(s).
|
|
|
|
DenseMap<MDString*, MDNode*> ErrorNode;
|
|
|
|
DenseMap<MDString*, MDNode*> WarningNode;
|
|
|
|
DenseMap<MDString*, MDNode*> OverrideNode;
|
|
|
|
DenseMap<MDString*, SmallSetVector<MDNode*, 8> > RequireNodes;
|
|
|
|
SmallSetVector<MDString*, 16> SeenIDs;
|
|
|
|
|
|
|
|
HasErr |= categorizeModuleFlagNodes(SrcModFlags, ErrorNode, WarningNode,
|
|
|
|
OverrideNode, RequireNodes, SeenIDs);
|
|
|
|
HasErr |= categorizeModuleFlagNodes(DstModFlags, ErrorNode, WarningNode,
|
|
|
|
OverrideNode, RequireNodes, SeenIDs);
|
|
|
|
|
|
|
|
// Check that there isn't both an error and warning node for a flag.
|
|
|
|
for (SmallSetVector<MDString*, 16>::iterator
|
|
|
|
I = SeenIDs.begin(), E = SeenIDs.end(); I != E; ++I) {
|
|
|
|
MDString *ID = *I;
|
|
|
|
if (ErrorNode[ID] && WarningNode[ID])
|
2012-02-14 17:13:54 +08:00
|
|
|
HasErr = emitError("linking module flags '" + ID->getString() +
|
2012-02-11 19:38:06 +08:00
|
|
|
"': IDs have conflicting behaviors");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Early exit if we had an error.
|
|
|
|
if (HasErr) return true;
|
|
|
|
|
|
|
|
// Get the destination's module flags ready for new operands.
|
|
|
|
DstModFlags->dropAllReferences();
|
|
|
|
|
|
|
|
// Add all of the module flags to the destination module.
|
|
|
|
DenseMap<MDString*, SmallVector<MDNode*, 4> > AddedNodes;
|
|
|
|
for (SmallSetVector<MDString*, 16>::iterator
|
|
|
|
I = SeenIDs.begin(), E = SeenIDs.end(); I != E; ++I) {
|
|
|
|
MDString *ID = *I;
|
|
|
|
if (OverrideNode[ID]) {
|
|
|
|
DstModFlags->addOperand(OverrideNode[ID]);
|
|
|
|
AddedNodes[ID].push_back(OverrideNode[ID]);
|
|
|
|
} else if (ErrorNode[ID]) {
|
|
|
|
DstModFlags->addOperand(ErrorNode[ID]);
|
|
|
|
AddedNodes[ID].push_back(ErrorNode[ID]);
|
|
|
|
} else if (WarningNode[ID]) {
|
|
|
|
DstModFlags->addOperand(WarningNode[ID]);
|
|
|
|
AddedNodes[ID].push_back(WarningNode[ID]);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (SmallSetVector<MDNode*, 8>::iterator
|
|
|
|
II = RequireNodes[ID].begin(), IE = RequireNodes[ID].end();
|
|
|
|
II != IE; ++II)
|
|
|
|
DstModFlags->addOperand(*II);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now check that all of the requirements have been satisfied.
|
|
|
|
for (SmallSetVector<MDString*, 16>::iterator
|
|
|
|
I = SeenIDs.begin(), E = SeenIDs.end(); I != E; ++I) {
|
|
|
|
MDString *ID = *I;
|
|
|
|
SmallSetVector<MDNode*, 8> &Set = RequireNodes[ID];
|
|
|
|
|
|
|
|
for (SmallSetVector<MDNode*, 8>::iterator
|
|
|
|
II = Set.begin(), IE = Set.end(); II != IE; ++II) {
|
|
|
|
MDNode *Node = *II;
|
|
|
|
assert(isa<MDNode>(Node->getOperand(2)) &&
|
|
|
|
"Module flag's third operand must be an MDNode!");
|
|
|
|
MDNode *Val = cast<MDNode>(Node->getOperand(2));
|
|
|
|
|
|
|
|
MDString *ReqID = cast<MDString>(Val->getOperand(0));
|
|
|
|
Value *ReqVal = Val->getOperand(1);
|
|
|
|
|
|
|
|
bool HasValue = false;
|
|
|
|
for (SmallVectorImpl<MDNode*>::iterator
|
|
|
|
RI = AddedNodes[ReqID].begin(), RE = AddedNodes[ReqID].end();
|
|
|
|
RI != RE; ++RI) {
|
|
|
|
MDNode *ReqNode = *RI;
|
|
|
|
if (ReqNode->getOperand(2) == ReqVal) {
|
|
|
|
HasValue = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!HasValue)
|
2012-02-14 17:13:54 +08:00
|
|
|
HasErr = emitError("linking module flags '" + ReqID->getString() +
|
|
|
|
"': does not have the required value");
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return HasErr;
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
bool ModuleLinker::run() {
|
2012-02-11 19:38:06 +08:00
|
|
|
assert(DstM && "Null destination module");
|
|
|
|
assert(SrcM && "Null source module");
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Inherit the target data from the source module if the destination module
|
|
|
|
// doesn't have one already.
|
|
|
|
if (DstM->getDataLayout().empty() && !SrcM->getDataLayout().empty())
|
|
|
|
DstM->setDataLayout(SrcM->getDataLayout());
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2008-02-20 02:49:08 +08:00
|
|
|
// Copy the target triple from the source to dest if the dest's is empty.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (DstM->getTargetTriple().empty() && !SrcM->getTargetTriple().empty())
|
|
|
|
DstM->setTargetTriple(SrcM->getTargetTriple());
|
2009-03-03 15:22:23 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!SrcM->getDataLayout().empty() && !DstM->getDataLayout().empty() &&
|
|
|
|
SrcM->getDataLayout() != DstM->getDataLayout())
|
2009-08-23 12:37:46 +08:00
|
|
|
errs() << "WARNING: Linking two modules of different data layouts!\n";
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!SrcM->getTargetTriple().empty() &&
|
|
|
|
DstM->getTargetTriple() != SrcM->getTargetTriple()) {
|
2010-12-30 10:49:45 +08:00
|
|
|
errs() << "WARNING: Linking two modules of different target triples: ";
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!SrcM->getModuleIdentifier().empty())
|
|
|
|
errs() << SrcM->getModuleIdentifier() << ": ";
|
|
|
|
errs() << "'" << SrcM->getTargetTriple() << "' and '"
|
|
|
|
<< DstM->getTargetTriple() << "'\n";
|
2010-12-30 10:49:45 +08:00
|
|
|
}
|
2005-04-22 06:55:34 +08:00
|
|
|
|
2008-02-20 02:49:08 +08:00
|
|
|
// Append the module inline asm string.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (!SrcM->getModuleInlineAsm().empty()) {
|
|
|
|
if (DstM->getModuleInlineAsm().empty())
|
|
|
|
DstM->setModuleInlineAsm(SrcM->getModuleInlineAsm());
|
2006-01-24 07:08:37 +08:00
|
|
|
else
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
DstM->setModuleInlineAsm(DstM->getModuleInlineAsm()+"\n"+
|
|
|
|
SrcM->getModuleInlineAsm());
|
2006-01-24 07:08:37 +08:00
|
|
|
}
|
2009-03-03 15:22:23 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Loop over all of the linked values to compute type mappings.
|
|
|
|
computeTypeMapping();
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Insert all of the globals in src into the DstM module... without linking
|
2004-11-13 04:37:43 +08:00
|
|
|
// initializers (which could refer to functions not yet mapped over).
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
for (Module::global_iterator I = SrcM->global_begin(),
|
|
|
|
E = SrcM->global_end(); I != E; ++I)
|
|
|
|
if (linkGlobalProto(I))
|
|
|
|
return true;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
|
|
|
// Link the functions together between the two modules, without doing function
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// bodies... this just adds external function prototypes to the DstM
|
2004-11-13 04:37:43 +08:00
|
|
|
// function... We do this so that when we begin processing function bodies,
|
|
|
|
// all of the global values that may be referenced are available in our
|
|
|
|
// ValueMap.
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
for (Module::iterator I = SrcM->begin(), E = SrcM->end(); I != E; ++I)
|
|
|
|
if (linkFunctionProto(I))
|
|
|
|
return true;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// If there were any aliases, link them now.
|
|
|
|
for (Module::alias_iterator I = SrcM->alias_begin(),
|
|
|
|
E = SrcM->alias_end(); I != E; ++I)
|
|
|
|
if (linkAliasProto(I))
|
|
|
|
return true;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
for (unsigned i = 0, e = AppendingVars.size(); i != e; ++i)
|
|
|
|
linkAppendingVarInit(AppendingVars[i]);
|
|
|
|
|
|
|
|
// Update the initializers in the DstM module now that all globals that may
|
|
|
|
// be referenced are in DstM.
|
|
|
|
linkGlobalInits();
|
|
|
|
|
|
|
|
// Link in the function bodies that are defined in the source module into
|
|
|
|
// DstM.
|
|
|
|
for (Module::iterator SF = SrcM->begin(), E = SrcM->end(); SF != E; ++SF) {
|
2011-10-15 06:17:46 +08:00
|
|
|
// Skip if not linking from source.
|
|
|
|
if (DoNotLinkFromSource.count(SF)) continue;
|
|
|
|
|
|
|
|
// Skip if no body (function is external) or materialize.
|
|
|
|
if (SF->isDeclaration()) {
|
|
|
|
if (!SF->isMaterializable())
|
|
|
|
continue;
|
|
|
|
if (SF->Materialize(&ErrorMsg))
|
|
|
|
return true;
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
|
|
|
|
linkFunctionBody(cast<Function>(ValueMap[SF]), SF);
|
2012-03-23 15:22:49 +08:00
|
|
|
SF->Dematerialize();
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Resolve all uses of aliases with aliasees.
|
|
|
|
linkAliasBodies();
|
2008-03-06 07:08:47 +08:00
|
|
|
|
2012-02-11 19:38:06 +08:00
|
|
|
// Remap all of the named MDNodes in Src into the DstM module. We do this
|
2011-08-05 03:44:28 +08:00
|
|
|
// after linking GlobalValues so that MDNodes that reference GlobalValues
|
|
|
|
// are properly remapped.
|
|
|
|
linkNamedMDNodes();
|
|
|
|
|
2012-02-11 19:38:06 +08:00
|
|
|
// Merge the module flags into the DstM module.
|
|
|
|
if (linkModuleFlagsMetadata())
|
|
|
|
return true;
|
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// Process vector of lazily linked in functions.
|
|
|
|
bool LinkedInAnyFunctions;
|
|
|
|
do {
|
|
|
|
LinkedInAnyFunctions = false;
|
|
|
|
|
|
|
|
for(std::vector<Function*>::iterator I = LazilyLinkFunctions.begin(),
|
|
|
|
E = LazilyLinkFunctions.end(); I != E; ++I) {
|
|
|
|
if (!*I)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Function *SF = *I;
|
|
|
|
Function *DF = cast<Function>(ValueMap[SF]);
|
|
|
|
|
|
|
|
if (!DF->use_empty()) {
|
|
|
|
|
|
|
|
// Materialize if necessary.
|
|
|
|
if (SF->isDeclaration()) {
|
|
|
|
if (!SF->isMaterializable())
|
|
|
|
continue;
|
|
|
|
if (SF->Materialize(&ErrorMsg))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Link in function body.
|
|
|
|
linkFunctionBody(DF, SF);
|
2012-03-23 15:22:49 +08:00
|
|
|
SF->Dematerialize();
|
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// "Remove" from vector by setting the element to 0.
|
|
|
|
*I = 0;
|
|
|
|
|
|
|
|
// Set flag to indicate we may have more functions to lazily link in
|
|
|
|
// since we linked in a function.
|
|
|
|
LinkedInAnyFunctions = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} while (LinkedInAnyFunctions);
|
|
|
|
|
|
|
|
// Remove any prototypes of functions that were not actually linked in.
|
|
|
|
for(std::vector<Function*>::iterator I = LazilyLinkFunctions.begin(),
|
|
|
|
E = LazilyLinkFunctions.end(); I != E; ++I) {
|
|
|
|
if (!*I)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Function *SF = *I;
|
|
|
|
Function *DF = cast<Function>(ValueMap[SF]);
|
|
|
|
if (DF->use_empty())
|
|
|
|
DF->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
// Now that all of the types from the source are used, resolve any structs
|
|
|
|
// copied over to the dest that didn't exist there.
|
|
|
|
TypeMap.linkDefinedTypeBodies();
|
|
|
|
|
2004-11-13 04:37:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// LinkModules entrypoint.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// LinkModules - This function links two modules together, with the resulting
|
|
|
|
/// left module modified to be the composite of the two input modules. If an
|
|
|
|
/// error occurs, true is returned and ErrorMsg (if not null) is set to indicate
|
|
|
|
/// the problem. Upon failure, the Dest module could be in a modified state,
|
|
|
|
/// and shouldn't be relied on to be consistent.
|
2011-10-11 08:24:54 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src, unsigned Mode,
|
|
|
|
std::string *ErrorMsg) {
|
|
|
|
ModuleLinker TheLinker(Dest, Src, Mode);
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
if (TheLinker.run()) {
|
|
|
|
if (ErrorMsg) *ErrorMsg = TheLinker.ErrorMsg;
|
|
|
|
return true;
|
|
|
|
}
|
It's possible for two types, which are isomorphic, to be added to the
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
llvm-svn: 153351
2012-03-24 07:17:38 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
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
2011-07-10 01:41:24 +08:00
|
|
|
return false;
|
|
|
|
}
|
2012-05-09 16:55:40 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// C API.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
LLVMBool LLVMLinkModules(LLVMModuleRef Dest, LLVMModuleRef Src,
|
|
|
|
LLVMLinkerMode Mode, char **OutMessages) {
|
|
|
|
std::string Messages;
|
|
|
|
LLVMBool Result = Linker::LinkModules(unwrap(Dest), unwrap(Src),
|
|
|
|
Mode, OutMessages? &Messages : 0);
|
|
|
|
if (OutMessages)
|
|
|
|
*OutMessages = strdup(Messages.c_str());
|
|
|
|
return Result;
|
|
|
|
}
|