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.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-03-06 11:42:23 +08:00
|
|
|
#include "llvm/Linker/Linker.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm-c/Linker.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"
|
2013-03-19 23:26:24 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2013-01-07 23:43:51 +08:00
|
|
|
#include "llvm/IR/TypeFinder.h"
|
2014-02-07 02:01:56 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2012-03-23 04:28:27 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2011-10-11 08:24:54 +08:00
|
|
|
#include "llvm/Transforms/Utils/Cloning.h"
|
2013-10-12 08:55:57 +08:00
|
|
|
#include <cctype>
|
2014-06-28 02:38:12 +08:00
|
|
|
#include <tuple>
|
2004-11-13 04:37:43 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-02-07 02:01:56 +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
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// TypeMap implementation.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2008-06-17 05:00:18 +08:00
|
|
|
namespace {
|
2013-05-04 13:05:18 +08:00
|
|
|
typedef SmallPtrSet<StructType*, 32> TypeSet;
|
|
|
|
|
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;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
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;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-12-20 08:03:52 +08:00
|
|
|
/// 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:
|
2013-05-04 13:05:18 +08:00
|
|
|
TypeMapTy(TypeSet &Set) : DstStructTypesSet(Set) {}
|
|
|
|
|
|
|
|
TypeSet &DstStructTypesSet;
|
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();
|
2014-05-09 22:39:25 +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 *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: ";
|
2014-08-12 11:24:59 +08:00
|
|
|
I->first->print(dbgs());
|
2012-03-23 04:28:27 +08:00
|
|
|
dbgs() << " => ";
|
2014-08-12 11:24:59 +08:00
|
|
|
I->second->print(dbgs());
|
2012-03-23 04:28:27 +08:00
|
|
|
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.
|
2014-03-05 15:52:44 +08:00
|
|
|
Type *remapType(Type *SrcTy) override {
|
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 get(SrcTy);
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +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;
|
2014-05-09 22:39:25 +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 (DstTy == SrcTy) {
|
|
|
|
Entry = DstTy;
|
|
|
|
return;
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +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
|
|
|
}
|
2014-05-09 22:39:25 +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
|
|
|
}
|
2014-05-09 22:39:25 +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;
|
2014-05-09 22:39:25 +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
|
|
|
// 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;
|
2014-05-09 22:39:25 +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)) {
|
2013-01-10 18:49:36 +08:00
|
|
|
if (DVTy->getNumElements() != cast<VectorType>(SrcTy)->getNumElements())
|
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-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;
|
2014-05-09 22:39:25 +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 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;
|
2014-05-09 22:39:25 +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
|
|
|
// 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]);
|
2014-05-09 22:39:25 +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
|
|
|
// 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?");
|
2014-05-09 22:39:25 +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
|
|
|
// 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));
|
2014-05-09 22:39:25 +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
|
|
|
DstSTy->setBody(Elements, SrcSTy->isPacked());
|
2014-05-09 22:39:25 +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 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();
|
2014-05-09 22:39:25 +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 (!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
|
|
|
}
|
2014-05-09 22:39:25 +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);
|
2014-05-09 22:39:25 +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 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;
|
2014-05-09 22:39:25 +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;
|
2014-05-09 22:39:25 +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
|
|
|
// 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);
|
|
|
|
}
|
2014-05-09 22:39:25 +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 our type while recursively processing stuff, just use it.
|
|
|
|
Entry = &MappedTypes[Ty];
|
|
|
|
if (*Entry) return *Entry;
|
2014-05-09 22:39:25 +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 all of the element types mapped directly over, then the type is usable
|
|
|
|
// as-is.
|
|
|
|
if (!AnyChange)
|
|
|
|
return *Entry = Ty;
|
2014-05-09 22:39:25 +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, 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());
|
2014-05-09 22:39:25 +08:00
|
|
|
case Type::VectorTyID:
|
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 *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);
|
2014-05-09 22:39:25 +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 type is opaque, we can just use it directly.
|
2013-05-04 13:05:18 +08:00
|
|
|
if (STy->isOpaque()) {
|
|
|
|
// A named structure type from src module is used. Add it to the Set of
|
|
|
|
// identified structs in the destination module.
|
|
|
|
DstStructTypesSet.insert(STy);
|
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 *Entry = STy;
|
2013-05-04 13:05:18 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +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());
|
2013-05-04 13:05:18 +08:00
|
|
|
// A new identified structure type was created. Add it to the set of
|
|
|
|
// identified structs in the destination module.
|
|
|
|
DstStructTypesSet.insert(DTy);
|
2011-12-20 08:03:52 +08:00
|
|
|
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 {
|
2013-05-28 23:17:05 +08:00
|
|
|
class ModuleLinker;
|
|
|
|
|
|
|
|
/// ValueMaterializerTy - Creates prototypes for functions that are lazily
|
|
|
|
/// linked on the fly. This speeds up linking for modules with many
|
|
|
|
/// lazily linked functions of which few get used.
|
|
|
|
class ValueMaterializerTy : public ValueMaterializer {
|
|
|
|
TypeMapTy &TypeMap;
|
|
|
|
Module *DstM;
|
|
|
|
std::vector<Function*> &LazilyLinkFunctions;
|
|
|
|
public:
|
|
|
|
ValueMaterializerTy(TypeMapTy &TypeMap, Module *DstM,
|
|
|
|
std::vector<Function*> &LazilyLinkFunctions) :
|
|
|
|
ValueMaterializer(), TypeMap(TypeMap), DstM(DstM),
|
|
|
|
LazilyLinkFunctions(LazilyLinkFunctions) {
|
|
|
|
}
|
|
|
|
|
2014-03-05 15:52:44 +08:00
|
|
|
Value *materializeValueFor(Value *V) override;
|
2013-05-28 23:17:05 +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 - This is an implementation class for the LinkModules
|
|
|
|
/// function, which is the entrypoint for this file.
|
|
|
|
class ModuleLinker {
|
|
|
|
Module *DstM, *SrcM;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
|
|
|
TypeMapTy TypeMap;
|
2013-05-28 23:17:05 +08:00
|
|
|
ValueMaterializerTy ValMaterializer;
|
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 - 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;
|
2014-05-09 22:39:25 +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
|
|
|
struct AppendingVarInfo {
|
|
|
|
GlobalVariable *NewGV; // New aggregate global in dest module.
|
|
|
|
Constant *DstInit; // Old initializer from dest module.
|
|
|
|
Constant *SrcInit; // Old initializer from src module.
|
|
|
|
};
|
2014-05-09 22:39:25 +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
|
|
|
std::vector<AppendingVarInfo> AppendingVars;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
unsigned Mode; // Mode to treat source module.
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Set of items not to link in from source.
|
|
|
|
SmallPtrSet<const Value*, 16> DoNotLinkFromSource;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// Vector of functions to lazily link in.
|
2013-03-28 01:54:41 +08:00
|
|
|
std::vector<Function*> LazilyLinkFunctions;
|
2014-02-21 06:19:24 +08:00
|
|
|
|
|
|
|
bool SuppressWarnings;
|
2014-05-09 22:39:25 +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
|
|
|
public:
|
|
|
|
std::string ErrorMsg;
|
2014-02-21 06:19:24 +08:00
|
|
|
|
|
|
|
ModuleLinker(Module *dstM, TypeSet &Set, Module *srcM, unsigned mode,
|
|
|
|
bool SuppressWarnings=false)
|
|
|
|
: DstM(dstM), SrcM(srcM), TypeMap(Set),
|
|
|
|
ValMaterializer(TypeMap, DstM, LazilyLinkFunctions), Mode(mode),
|
|
|
|
SuppressWarnings(SuppressWarnings) {}
|
|
|
|
|
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();
|
2014-05-09 22:39:25 +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
|
|
|
private:
|
2014-09-09 23:21:00 +08:00
|
|
|
bool shouldLinkFromSource(const GlobalValue &Dest, const GlobalValue &Src);
|
|
|
|
|
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
|
|
|
/// emitError - Helper method for setting a message and returning an error
|
|
|
|
/// code.
|
|
|
|
bool emitError(const Twine &Message) {
|
|
|
|
ErrorMsg = Message.str();
|
|
|
|
return true;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
bool getComdatLeader(Module *M, StringRef ComdatName,
|
|
|
|
const GlobalVariable *&GVar);
|
|
|
|
bool computeResultingSelectionKind(StringRef ComdatName,
|
|
|
|
Comdat::SelectionKind Src,
|
|
|
|
Comdat::SelectionKind Dst,
|
|
|
|
Comdat::SelectionKind &Result,
|
|
|
|
bool &LinkFromSrc);
|
|
|
|
std::map<const Comdat *, std::pair<Comdat::SelectionKind, bool>>
|
|
|
|
ComdatsChosen;
|
|
|
|
bool getComdatResult(const Comdat *SrcC, Comdat::SelectionKind &SK,
|
|
|
|
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
|
|
|
/// 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())
|
2014-04-15 14:32:26 +08:00
|
|
|
return nullptr;
|
2014-05-09 22:39:25 +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());
|
2014-04-15 14:32:26 +08:00
|
|
|
if (!DGV) return nullptr;
|
2014-05-09 22:39:25 +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())
|
2014-04-15 14:32:26 +08:00
|
|
|
return nullptr;
|
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 do in fact link to the destination global.
|
|
|
|
return DGV;
|
|
|
|
}
|
2014-05-09 22:39:25 +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 computeTypeMapping();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-08-13 00:46:37 +08:00
|
|
|
void upgradeMismatchedGlobalArray(StringRef Name);
|
|
|
|
void upgradeMismatchedGlobals();
|
|
|
|
|
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();
|
2014-05-09 22:39:25 +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 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.
|
2014-05-14 02:45:48 +08:00
|
|
|
auto *DestGO = dyn_cast<GlobalObject>(DestGV);
|
2014-05-06 22:51:36 +08:00
|
|
|
unsigned Alignment;
|
2014-05-14 02:45:48 +08:00
|
|
|
if (DestGO)
|
|
|
|
Alignment = std::max(DestGO->getAlignment(), SrcGV->getAlignment());
|
2014-05-06 22:51:36 +08:00
|
|
|
|
2008-05-27 03:58:59 +08:00
|
|
|
DestGV->copyAttributesFrom(SrcGV);
|
2014-05-06 22:51:36 +08:00
|
|
|
|
2014-05-14 02:45:48 +08:00
|
|
|
if (DestGO)
|
|
|
|
DestGO->setAlignment(Alignment);
|
2014-05-06 22:51:36 +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(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;
|
|
|
|
}
|
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
Value *ValueMaterializerTy::materializeValueFor(Value *V) {
|
|
|
|
Function *SF = dyn_cast<Function>(V);
|
|
|
|
if (!SF)
|
2014-04-15 14:32:26 +08:00
|
|
|
return nullptr;
|
2013-05-28 23:17:05 +08:00
|
|
|
|
|
|
|
Function *DF = Function::Create(TypeMap.get(SF->getFunctionType()),
|
|
|
|
SF->getLinkage(), SF->getName(), DstM);
|
|
|
|
copyGVAttributes(DF, SF);
|
|
|
|
|
2014-08-16 04:17:08 +08:00
|
|
|
if (Comdat *SC = SF->getComdat()) {
|
|
|
|
Comdat *DC = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
DF->setComdat(DC);
|
|
|
|
}
|
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
LazilyLinkFunctions.push_back(SF);
|
|
|
|
return DF;
|
|
|
|
}
|
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
bool ModuleLinker::getComdatLeader(Module *M, StringRef ComdatName,
|
|
|
|
const GlobalVariable *&GVar) {
|
|
|
|
const GlobalValue *GVal = M->getNamedValue(ComdatName);
|
|
|
|
if (const auto *GA = dyn_cast_or_null<GlobalAlias>(GVal)) {
|
|
|
|
GVal = GA->getBaseObject();
|
|
|
|
if (!GVal)
|
|
|
|
// We cannot resolve the size of the aliasee yet.
|
|
|
|
return emitError("Linking COMDATs named '" + ComdatName +
|
|
|
|
"': COMDAT key involves incomputable alias size.");
|
|
|
|
}
|
|
|
|
|
|
|
|
GVar = dyn_cast_or_null<GlobalVariable>(GVal);
|
|
|
|
if (!GVar)
|
|
|
|
return emitError(
|
|
|
|
"Linking COMDATs named '" + ComdatName +
|
|
|
|
"': GlobalVariable required for data dependent selection!");
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ModuleLinker::computeResultingSelectionKind(StringRef ComdatName,
|
|
|
|
Comdat::SelectionKind Src,
|
|
|
|
Comdat::SelectionKind Dst,
|
|
|
|
Comdat::SelectionKind &Result,
|
|
|
|
bool &LinkFromSrc) {
|
|
|
|
// The ability to mix Comdat::SelectionKind::Any with
|
|
|
|
// Comdat::SelectionKind::Largest is a behavior that comes from COFF.
|
|
|
|
bool DstAnyOrLargest = Dst == Comdat::SelectionKind::Any ||
|
|
|
|
Dst == Comdat::SelectionKind::Largest;
|
|
|
|
bool SrcAnyOrLargest = Src == Comdat::SelectionKind::Any ||
|
|
|
|
Src == Comdat::SelectionKind::Largest;
|
|
|
|
if (DstAnyOrLargest && SrcAnyOrLargest) {
|
|
|
|
if (Dst == Comdat::SelectionKind::Largest ||
|
|
|
|
Src == Comdat::SelectionKind::Largest)
|
|
|
|
Result = Comdat::SelectionKind::Largest;
|
|
|
|
else
|
|
|
|
Result = Comdat::SelectionKind::Any;
|
|
|
|
} else if (Src == Dst) {
|
|
|
|
Result = Dst;
|
|
|
|
} else {
|
|
|
|
return emitError("Linking COMDATs named '" + ComdatName +
|
|
|
|
"': invalid selection kinds!");
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (Result) {
|
|
|
|
case Comdat::SelectionKind::Any:
|
|
|
|
// Go with Dst.
|
|
|
|
LinkFromSrc = false;
|
|
|
|
break;
|
|
|
|
case Comdat::SelectionKind::NoDuplicates:
|
|
|
|
return emitError("Linking COMDATs named '" + ComdatName +
|
|
|
|
"': noduplicates has been violated!");
|
|
|
|
case Comdat::SelectionKind::ExactMatch:
|
|
|
|
case Comdat::SelectionKind::Largest:
|
|
|
|
case Comdat::SelectionKind::SameSize: {
|
|
|
|
const GlobalVariable *DstGV;
|
|
|
|
const GlobalVariable *SrcGV;
|
|
|
|
if (getComdatLeader(DstM, ComdatName, DstGV) ||
|
|
|
|
getComdatLeader(SrcM, ComdatName, SrcGV))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
const DataLayout *DstDL = DstM->getDataLayout();
|
|
|
|
const DataLayout *SrcDL = SrcM->getDataLayout();
|
|
|
|
if (!DstDL || !SrcDL) {
|
|
|
|
return emitError(
|
|
|
|
"Linking COMDATs named '" + ComdatName +
|
|
|
|
"': can't do size dependent selection without DataLayout!");
|
|
|
|
}
|
|
|
|
uint64_t DstSize =
|
|
|
|
DstDL->getTypeAllocSize(DstGV->getType()->getPointerElementType());
|
|
|
|
uint64_t SrcSize =
|
|
|
|
SrcDL->getTypeAllocSize(SrcGV->getType()->getPointerElementType());
|
|
|
|
if (Result == Comdat::SelectionKind::ExactMatch) {
|
|
|
|
if (SrcGV->getInitializer() != DstGV->getInitializer())
|
|
|
|
return emitError("Linking COMDATs named '" + ComdatName +
|
|
|
|
"': ExactMatch violated!");
|
|
|
|
LinkFromSrc = false;
|
|
|
|
} else if (Result == Comdat::SelectionKind::Largest) {
|
|
|
|
LinkFromSrc = SrcSize > DstSize;
|
|
|
|
} else if (Result == Comdat::SelectionKind::SameSize) {
|
|
|
|
if (SrcSize != DstSize)
|
|
|
|
return emitError("Linking COMDATs named '" + ComdatName +
|
|
|
|
"': SameSize violated!");
|
|
|
|
LinkFromSrc = false;
|
|
|
|
} else {
|
|
|
|
llvm_unreachable("unknown selection kind");
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ModuleLinker::getComdatResult(const Comdat *SrcC,
|
|
|
|
Comdat::SelectionKind &Result,
|
|
|
|
bool &LinkFromSrc) {
|
2014-08-12 01:07:34 +08:00
|
|
|
Comdat::SelectionKind SSK = SrcC->getSelectionKind();
|
2014-06-28 02:19:56 +08:00
|
|
|
StringRef ComdatName = SrcC->getName();
|
|
|
|
Module::ComdatSymTabType &ComdatSymTab = DstM->getComdatSymbolTable();
|
|
|
|
Module::ComdatSymTabType::iterator DstCI = ComdatSymTab.find(ComdatName);
|
2014-08-12 00:55:42 +08:00
|
|
|
|
2014-08-12 01:07:34 +08:00
|
|
|
if (DstCI == ComdatSymTab.end()) {
|
|
|
|
// Use the comdat if it is only available in one of the modules.
|
|
|
|
LinkFromSrc = true;
|
|
|
|
Result = SSK;
|
2014-08-12 00:55:42 +08:00
|
|
|
return false;
|
2014-08-12 01:07:34 +08:00
|
|
|
}
|
2014-08-12 00:55:42 +08:00
|
|
|
|
|
|
|
const Comdat *DstC = &DstCI->second;
|
|
|
|
Comdat::SelectionKind DSK = DstC->getSelectionKind();
|
|
|
|
return computeResultingSelectionKind(ComdatName, SSK, DSK, Result,
|
|
|
|
LinkFromSrc);
|
2014-06-28 02:19:56 +08:00
|
|
|
}
|
2013-05-28 23:17:05 +08:00
|
|
|
|
2014-09-09 22:07:40 +08:00
|
|
|
// FIXME: Duplicated from the gold plugin. This should be refactored somewhere.
|
|
|
|
static bool isDeclaration(const GlobalValue &V) {
|
|
|
|
if (V.hasAvailableExternallyLinkage())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (V.isMaterializable())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return V.isDeclaration();
|
|
|
|
}
|
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
bool ModuleLinker::shouldLinkFromSource(const GlobalValue &Dest,
|
|
|
|
const GlobalValue &Src) {
|
|
|
|
bool SrcIsDeclaration = isDeclaration(Src);
|
|
|
|
bool DestIsDeclaration = isDeclaration(Dest);
|
|
|
|
|
2014-09-09 23:59:12 +08:00
|
|
|
// FIXME: Make datalayout mandatory and just use getDataLayout().
|
|
|
|
DataLayout DL(Dest.getParent());
|
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
if (SrcIsDeclaration) {
|
|
|
|
// If Src is external or if both Src & Dest are external.. Just link the
|
|
|
|
// external globals, we aren't adding anything.
|
|
|
|
if (Src.hasDLLImportStorageClass())
|
|
|
|
// If one of GVs is marked as DLLImport, result should be dllimport'ed.
|
|
|
|
return DestIsDeclaration;
|
|
|
|
// If the Dest is weak, use the source linkage.
|
|
|
|
return Dest.hasExternalWeakLinkage();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DestIsDeclaration)
|
|
|
|
// If Dest is external but Src is not:
|
|
|
|
return true;
|
|
|
|
|
2014-09-09 23:59:12 +08:00
|
|
|
if (Src.hasCommonLinkage()) {
|
|
|
|
if (Dest.hasLinkOnceLinkage() || Dest.hasWeakLinkage())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (!Dest.hasCommonLinkage())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
uint64_t DestSize = DL.getTypeAllocSize(Dest.getType()->getElementType());
|
|
|
|
uint64_t SrcSize = DL.getTypeAllocSize(Src.getType()->getElementType());
|
|
|
|
return SrcSize > DestSize;
|
|
|
|
}
|
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
if (Src.isWeakForLinker()) {
|
|
|
|
assert(!Dest.hasExternalWeakLinkage());
|
|
|
|
assert(!Dest.hasAvailableExternallyLinkage());
|
2014-09-09 23:59:12 +08:00
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
if (Dest.hasLinkOnceLinkage() && Src.hasWeakLinkage())
|
|
|
|
return true;
|
|
|
|
|
2014-09-09 23:59:12 +08:00
|
|
|
return false;
|
2014-09-09 23:21:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (Dest.isWeakForLinker()) {
|
|
|
|
assert(Src.hasExternalLinkage());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(!Src.hasExternalWeakLinkage());
|
|
|
|
assert(!Dest.hasExternalWeakLinkage());
|
|
|
|
assert(Dest.hasExternalLinkage() && Src.hasExternalLinkage() &&
|
|
|
|
"Unexpected linkage type!");
|
|
|
|
return emitError("Linking globals named '" + Src.getName() +
|
|
|
|
"': symbol multiply defined!");
|
|
|
|
}
|
|
|
|
|
2014-09-09 22:07:40 +08:00
|
|
|
/// This analyzes the two global values and determines what the result will look
|
|
|
|
/// like in the destination module. In particular, it 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!");
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
assert(ErrorMsg.empty());
|
|
|
|
LinkFromSrc = shouldLinkFromSource(*Dest, *Src);
|
|
|
|
if (!ErrorMsg.empty())
|
|
|
|
return true;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-09-09 23:21:00 +08:00
|
|
|
if (LinkFromSrc)
|
2004-12-04 06:18:41 +08:00
|
|
|
LT = Src->getLinkage();
|
2014-09-09 23:21:00 +08:00
|
|
|
else
|
|
|
|
LT = Dest->getLinkage();
|
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.
|
2014-05-08 06:55:46 +08:00
|
|
|
assert(!GlobalValue::isLocalLinkage(LT) &&
|
|
|
|
"Symbols with local linkage should not be merged");
|
2012-01-06 07:02:01 +08:00
|
|
|
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);
|
2014-04-15 14:32:26 +08:00
|
|
|
if (!DGV) continue;
|
2014-05-09 22:39:25 +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->hasAppendingLinkage() || !I->hasAppendingLinkage()) {
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), I->getType());
|
2014-05-09 22:39:25 +08:00
|
|
|
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
|
|
|
}
|
2014-05-09 22:39:25 +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
|
|
|
// 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
|
|
|
}
|
2014-05-09 22:39:25 +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-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;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2012-02-28 07:48:30 +08:00
|
|
|
// 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 ||
|
2013-02-13 05:21:59 +08:00
|
|
|
ST->getName().back() == '.' ||
|
|
|
|
!isdigit(static_cast<unsigned char>(ST->getName()[DotPos+1])))
|
2012-02-28 12:01:21 +08:00
|
|
|
continue;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
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.
|
2013-05-04 13:05:18 +08:00
|
|
|
if (!SrcStructTypesSet.count(DST) && TypeMap.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.
|
2014-05-09 22:39:25 +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
|
2014-05-09 22:39:25 +08:00
|
|
|
// any 'opaque' types in the dest module that are now resolved.
|
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.linkDefinedTypeBodies();
|
2009-08-12 02:01:24 +08:00
|
|
|
}
|
|
|
|
|
2014-08-13 00:46:37 +08:00
|
|
|
static void upgradeGlobalArray(GlobalVariable *GV) {
|
|
|
|
ArrayType *ATy = cast<ArrayType>(GV->getType()->getElementType());
|
|
|
|
StructType *OldTy = cast<StructType>(ATy->getElementType());
|
|
|
|
assert(OldTy->getNumElements() == 2 && "Expected to upgrade from 2 elements");
|
|
|
|
|
|
|
|
// Get the upgraded 3 element type.
|
|
|
|
PointerType *VoidPtrTy = Type::getInt8Ty(GV->getContext())->getPointerTo();
|
|
|
|
Type *Tys[3] = {OldTy->getElementType(0), OldTy->getElementType(1),
|
|
|
|
VoidPtrTy};
|
|
|
|
StructType *NewTy = StructType::get(GV->getContext(), Tys, false);
|
|
|
|
|
|
|
|
// Build new constants with a null third field filled in.
|
|
|
|
Constant *OldInitC = GV->getInitializer();
|
|
|
|
ConstantArray *OldInit = dyn_cast<ConstantArray>(OldInitC);
|
|
|
|
if (!OldInit && !isa<ConstantAggregateZero>(OldInitC))
|
|
|
|
// Invalid initializer; give up.
|
|
|
|
return;
|
|
|
|
std::vector<Constant *> Initializers;
|
|
|
|
if (OldInit && OldInit->getNumOperands()) {
|
|
|
|
Value *Null = Constant::getNullValue(VoidPtrTy);
|
|
|
|
for (Use &U : OldInit->operands()) {
|
|
|
|
ConstantStruct *Init = cast<ConstantStruct>(U.get());
|
|
|
|
Initializers.push_back(ConstantStruct::get(
|
|
|
|
NewTy, Init->getOperand(0), Init->getOperand(1), Null, nullptr));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(Initializers.size() == ATy->getNumElements() &&
|
|
|
|
"Failed to copy all array elements");
|
|
|
|
|
|
|
|
// Replace the old GV with a new one.
|
|
|
|
ATy = ArrayType::get(NewTy, Initializers.size());
|
|
|
|
Constant *NewInit = ConstantArray::get(ATy, Initializers);
|
|
|
|
GlobalVariable *NewGV = new GlobalVariable(
|
|
|
|
*GV->getParent(), ATy, GV->isConstant(), GV->getLinkage(), NewInit, "",
|
|
|
|
GV, GV->getThreadLocalMode(), GV->getType()->getAddressSpace(),
|
|
|
|
GV->isExternallyInitialized());
|
|
|
|
NewGV->copyAttributesFrom(GV);
|
|
|
|
NewGV->takeName(GV);
|
|
|
|
assert(GV->use_empty() && "program cannot use initializer list");
|
|
|
|
GV->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
void ModuleLinker::upgradeMismatchedGlobalArray(StringRef Name) {
|
|
|
|
// Look for the global arrays.
|
|
|
|
auto *DstGV = dyn_cast_or_null<GlobalVariable>(DstM->getNamedValue(Name));
|
|
|
|
if (!DstGV)
|
|
|
|
return;
|
|
|
|
auto *SrcGV = dyn_cast_or_null<GlobalVariable>(SrcM->getNamedValue(Name));
|
|
|
|
if (!SrcGV)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Check if the types already match.
|
|
|
|
auto *DstTy = cast<ArrayType>(DstGV->getType()->getElementType());
|
|
|
|
auto *SrcTy =
|
|
|
|
cast<ArrayType>(TypeMap.get(SrcGV->getType()->getElementType()));
|
|
|
|
if (DstTy == SrcTy)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Grab the element types. We can only upgrade an array of a two-field
|
|
|
|
// struct. Only bother if the other one has three-fields.
|
|
|
|
auto *DstEltTy = cast<StructType>(DstTy->getElementType());
|
|
|
|
auto *SrcEltTy = cast<StructType>(SrcTy->getElementType());
|
|
|
|
if (DstEltTy->getNumElements() == 2 && SrcEltTy->getNumElements() == 3) {
|
|
|
|
upgradeGlobalArray(DstGV);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (DstEltTy->getNumElements() == 3 && SrcEltTy->getNumElements() == 2)
|
|
|
|
upgradeGlobalArray(SrcGV);
|
|
|
|
|
|
|
|
// We can't upgrade any other differences.
|
|
|
|
}
|
|
|
|
|
|
|
|
void ModuleLinker::upgradeMismatchedGlobals() {
|
|
|
|
upgradeMismatchedGlobalArray("llvm.global_ctors");
|
|
|
|
upgradeMismatchedGlobalArray("llvm.global_dtors");
|
|
|
|
}
|
|
|
|
|
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) {
|
2014-05-09 22:39:25 +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!");
|
2014-05-09 22:39:25 +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
|
|
|
ArrayType *DstTy = cast<ArrayType>(DstGV->getType()->getElementType());
|
|
|
|
ArrayType *SrcTy =
|
|
|
|
cast<ArrayType>(TypeMap.get(SrcGV->getType()->getElementType()));
|
|
|
|
Type *EltTy = DstTy->getElementType();
|
2014-05-09 22:39:25 +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 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!");
|
2014-05-09 22:39:25 +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 (DstGV->getAlignment() != SrcGV->getAlignment())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different alignment need to be linked!");
|
2014-05-09 22:39:25 +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 (DstGV->getVisibility() != SrcGV->getVisibility())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different visibility need to be linked!");
|
2013-09-04 23:33:34 +08:00
|
|
|
|
|
|
|
if (DstGV->hasUnnamedAddr() != SrcGV->hasUnnamedAddr())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different unnamed_addr need to be linked!");
|
|
|
|
|
2014-06-03 10:41:57 +08:00
|
|
|
if (StringRef(DstGV->getSection()) != SrcGV->getSection())
|
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(
|
|
|
|
"Appending variables with different section name need to be linked!");
|
2014-05-09 22:39:25 +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
|
|
|
uint64_t NewSize = DstTy->getNumElements() + SrcTy->getNumElements();
|
|
|
|
ArrayType *NewType = ArrayType::get(EltTy, NewSize);
|
2014-05-09 22:39:25 +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
|
|
|
// Create the new global variable.
|
|
|
|
GlobalVariable *NG =
|
|
|
|
new GlobalVariable(*DstGV->getParent(), NewType, SrcGV->isConstant(),
|
2014-04-15 14:32:26 +08:00
|
|
|
DstGV->getLinkage(), /*init*/nullptr, /*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());
|
2014-05-09 22:39:25 +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
|
|
|
// Propagate alignment, visibility and section info.
|
2012-03-23 04:28:27 +08:00
|
|
|
copyGVAttributes(NG, DstGV);
|
2014-05-09 22:39:25 +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
|
|
|
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();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Track the source variable so we don't try to link it.
|
|
|
|
DoNotLinkFromSource.insert(SrcGV);
|
2014-05-09 22:39:25 +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;
|
|
|
|
}
|
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;
|
2013-09-04 22:05:09 +08:00
|
|
|
bool HasUnnamedAddr = SGV->hasUnnamedAddr();
|
2014-09-10 01:48:18 +08:00
|
|
|
unsigned Alignment = SGV->getAlignment();
|
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
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
bool LinkFromSrc = false;
|
|
|
|
Comdat *DC = nullptr;
|
|
|
|
if (const Comdat *SC = SGV->getComdat()) {
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
std::tie(SK, LinkFromSrc) = ComdatsChosen[SC];
|
|
|
|
DC = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
DC->setSelectionKind(SK);
|
|
|
|
}
|
|
|
|
|
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) {
|
2014-06-28 02:19:56 +08:00
|
|
|
if (!DC) {
|
|
|
|
// 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.
|
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
|
|
|
GlobalValue::VisibilityTypes NV;
|
|
|
|
if (getLinkageResult(DGV, SGV, NewLinkage, NV, LinkFromSrc))
|
|
|
|
return true;
|
|
|
|
NewVisibility = NV;
|
|
|
|
HasUnnamedAddr = HasUnnamedAddr && DGV->hasUnnamedAddr();
|
2014-09-10 01:48:18 +08:00
|
|
|
if (DGV->hasCommonLinkage() && SGV->hasCommonLinkage())
|
|
|
|
Alignment = std::max(Alignment, DGV->getAlignment());
|
|
|
|
else if (!LinkFromSrc)
|
|
|
|
Alignment = DGV->getAlignment();
|
2014-06-28 02:19:56 +08:00
|
|
|
|
|
|
|
// If we're not linking from the source, then keep the definition that we
|
|
|
|
// have.
|
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Special case for const propagation.
|
2014-09-10 01:48:18 +08:00
|
|
|
if (GlobalVariable *DGVar = dyn_cast<GlobalVariable>(DGV)) {
|
|
|
|
DGVar->setAlignment(Alignment);
|
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
if (DGVar->isDeclaration() && SGV->isConstant() &&
|
|
|
|
!DGVar->isConstant())
|
|
|
|
DGVar->setConstant(true);
|
2014-09-10 01:48:18 +08:00
|
|
|
}
|
2014-06-28 02:19:56 +08:00
|
|
|
|
|
|
|
// Set calculated linkage, visibility and unnamed_addr.
|
|
|
|
DGV->setLinkage(NewLinkage);
|
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
DGV->setUnnamedAddr(HasUnnamedAddr);
|
|
|
|
}
|
|
|
|
}
|
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 (!LinkFromSrc) {
|
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()));
|
2014-05-09 22:39:25 +08:00
|
|
|
|
|
|
|
// Track the source global so that we don't attempt to copy it over when
|
2011-10-11 08:24:54 +08:00
|
|
|
// processing global initializers.
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
2014-05-09 22:39:25 +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;
|
2008-07-14 15:23:24 +08:00
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
// If the Comdat this variable was inside of wasn't selected, skip it.
|
|
|
|
if (DC && !DGV && !LinkFromSrc) {
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
|
|
|
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
|
|
|
// 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()),
|
2014-04-15 14:32:26 +08:00
|
|
|
SGV->isConstant(), SGV->getLinkage(), /*init*/nullptr,
|
|
|
|
SGV->getName(), /*insertbefore*/nullptr,
|
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);
|
2014-09-10 01:48:18 +08:00
|
|
|
NewDGV->setAlignment(Alignment);
|
2012-01-06 07:02:01 +08:00
|
|
|
if (NewVisibility)
|
|
|
|
NewDGV->setVisibility(*NewVisibility);
|
2013-09-04 22:05:09 +08:00
|
|
|
NewDGV->setUnnamedAddr(HasUnnamedAddr);
|
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
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
if (DC)
|
|
|
|
NewDGV->setComdat(DC);
|
|
|
|
|
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
|
|
|
}
|
2014-05-09 22:39:25 +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;
|
2013-09-04 22:59:03 +08:00
|
|
|
bool HasUnnamedAddr = SF->hasUnnamedAddr();
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
bool LinkFromSrc = false;
|
|
|
|
Comdat *DC = nullptr;
|
|
|
|
if (const Comdat *SC = SF->getComdat()) {
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
std::tie(SK, LinkFromSrc) = ComdatsChosen[SC];
|
|
|
|
DC = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
DC->setSelectionKind(SK);
|
|
|
|
}
|
|
|
|
|
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) {
|
2014-06-28 02:19:56 +08:00
|
|
|
if (!DC) {
|
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
|
|
|
GlobalValue::VisibilityTypes NV;
|
|
|
|
if (getLinkageResult(DGV, SF, NewLinkage, NV, LinkFromSrc))
|
|
|
|
return true;
|
|
|
|
NewVisibility = NV;
|
|
|
|
HasUnnamedAddr = HasUnnamedAddr && DGV->hasUnnamedAddr();
|
|
|
|
|
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Set calculated linkage
|
|
|
|
DGV->setLinkage(NewLinkage);
|
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
DGV->setUnnamedAddr(HasUnnamedAddr);
|
|
|
|
}
|
|
|
|
}
|
2012-01-06 07:02:01 +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 (!LinkFromSrc) {
|
|
|
|
// Make sure to remember this mapping.
|
|
|
|
ValueMap[SF] = ConstantExpr::getBitCast(DGV, TypeMap.get(SF->getType()));
|
2014-05-09 22:39:25 +08:00
|
|
|
|
|
|
|
// Track the function from the source module so we don't attempt to remap
|
2011-10-11 08:24:54 +08:00
|
|
|
// it.
|
|
|
|
DoNotLinkFromSource.insert(SF);
|
2014-05-09 22:39:25 +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;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
// If the function is to be lazily linked, don't create it just yet.
|
|
|
|
// The ValueMaterializerTy will deal with creating it if it's used.
|
|
|
|
if (!DGV && (SF->hasLocalLinkage() || SF->hasLinkOnceLinkage() ||
|
|
|
|
SF->hasAvailableExternallyLinkage())) {
|
|
|
|
DoNotLinkFromSource.insert(SF);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
// If the Comdat this function was inside of wasn't selected, skip it.
|
|
|
|
if (DC && !DGV && !LinkFromSrc) {
|
|
|
|
DoNotLinkFromSource.insert(SF);
|
|
|
|
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
|
|
|
// 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);
|
2013-09-04 22:59:03 +08:00
|
|
|
NewDF->setUnnamedAddr(HasUnnamedAddr);
|
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
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
if (DC)
|
|
|
|
NewDF->setComdat(DC);
|
|
|
|
|
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();
|
|
|
|
}
|
2014-05-09 22:39:25 +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
|
|
|
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;
|
2014-06-06 09:20:28 +08:00
|
|
|
bool HasUnnamedAddr = SGA->hasUnnamedAddr();
|
2012-01-06 07:02:01 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
bool LinkFromSrc = false;
|
|
|
|
Comdat *DC = nullptr;
|
|
|
|
if (const Comdat *SC = SGA->getComdat()) {
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
std::tie(SK, LinkFromSrc) = ComdatsChosen[SC];
|
|
|
|
DC = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
DC->setSelectionKind(SK);
|
|
|
|
}
|
|
|
|
|
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) {
|
2014-06-28 02:19:56 +08:00
|
|
|
if (!DC) {
|
|
|
|
GlobalValue::LinkageTypes NewLinkage = GlobalValue::InternalLinkage;
|
|
|
|
GlobalValue::VisibilityTypes NV;
|
|
|
|
if (getLinkageResult(DGV, SGA, NewLinkage, NV, LinkFromSrc))
|
|
|
|
return true;
|
|
|
|
NewVisibility = NV;
|
|
|
|
HasUnnamedAddr = HasUnnamedAddr && DGV->hasUnnamedAddr();
|
|
|
|
|
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Set calculated linkage.
|
|
|
|
DGV->setLinkage(NewLinkage);
|
|
|
|
DGV->setVisibility(*NewVisibility);
|
|
|
|
DGV->setUnnamedAddr(HasUnnamedAddr);
|
|
|
|
}
|
|
|
|
}
|
2012-01-06 07:02:01 +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 (!LinkFromSrc) {
|
|
|
|
// Make sure to remember this mapping.
|
|
|
|
ValueMap[SGA] = ConstantExpr::getBitCast(DGV,TypeMap.get(SGA->getType()));
|
2014-05-09 22:39:25 +08:00
|
|
|
|
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);
|
2014-05-09 22:39:25 +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;
|
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
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
// If the Comdat this alias was inside of wasn't selected, skip it.
|
|
|
|
if (DC && !DGV && !LinkFromSrc) {
|
|
|
|
DoNotLinkFromSource.insert(SGA);
|
|
|
|
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
|
|
|
// If there is no linkage to be performed or we're linking from the source,
|
|
|
|
// bring over SGA.
|
2014-05-16 21:34:04 +08:00
|
|
|
auto *PTy = cast<PointerType>(TypeMap.get(SGA->getType()));
|
2014-05-18 05:29:57 +08:00
|
|
|
auto *NewDA =
|
|
|
|
GlobalAlias::create(PTy->getElementType(), PTy->getAddressSpace(),
|
|
|
|
SGA->getLinkage(), SGA->getName(), 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);
|
2014-06-06 09:20:28 +08:00
|
|
|
NewDA->setUnnamedAddr(HasUnnamedAddr);
|
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
|
|
|
|
2014-06-03 10:41:57 +08:00
|
|
|
if (DGV) {
|
|
|
|
// Any uses of DGV need to change to NewDA, with cast.
|
|
|
|
DGV->replaceAllUsesWith(ConstantExpr::getBitCast(NewDA, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
|
|
|
}
|
2014-05-09 22:39:25 +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
|
|
|
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
|
|
|
}
|
2014-05-09 22:39:25 +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.
|
2014-09-06 05:27:52 +08:00
|
|
|
SmallVector<Constant *, 16> DstElements;
|
|
|
|
getArrayElements(AVI.DstInit, DstElements);
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-09-06 05:27:52 +08:00
|
|
|
SmallVector<Constant *, 16> SrcElements;
|
|
|
|
getArrayElements(AVI.SrcInit, SrcElements);
|
2014-05-09 22:39:25 +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
|
|
|
ArrayType *NewType = cast<ArrayType>(AVI.NewGV->getType()->getElementType());
|
2014-09-06 05:27:52 +08:00
|
|
|
|
|
|
|
StringRef Name = AVI.NewGV->getName();
|
|
|
|
bool IsNewStructor =
|
|
|
|
(Name == "llvm.global_ctors" || Name == "llvm.global_dtors") &&
|
|
|
|
cast<StructType>(NewType->getElementType())->getNumElements() == 3;
|
|
|
|
|
|
|
|
for (auto *V : SrcElements) {
|
|
|
|
if (IsNewStructor) {
|
|
|
|
Constant *Key = V->getAggregateElement(2);
|
|
|
|
if (DoNotLinkFromSource.count(Key))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
DstElements.push_back(
|
|
|
|
MapValue(V, ValueMap, RF_None, &TypeMap, &ValMaterializer));
|
|
|
|
}
|
|
|
|
if (IsNewStructor) {
|
|
|
|
NewType = ArrayType::get(NewType->getElementType(), DstElements.size());
|
|
|
|
AVI.NewGV->mutateType(PointerType::get(NewType, 0));
|
|
|
|
}
|
|
|
|
|
|
|
|
AVI.NewGV->setInitializer(ConstantArray::get(NewType, DstElements));
|
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
|
|
|
}
|
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) {
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// Only process initialized GV's or ones not already in dest.
|
2014-05-09 22:39:25 +08:00
|
|
|
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,
|
2013-05-28 23:17:05 +08:00
|
|
|
RF_None, &TypeMap, &ValMaterializer));
|
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());
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
// 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)
|
2013-05-28 23:17:05 +08:00
|
|
|
RemapInstruction(I, ValueMap, RF_IgnoreMissingEntries,
|
|
|
|
&TypeMap, &ValMaterializer);
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2011-10-11 08:24:54 +08:00
|
|
|
} else {
|
|
|
|
// Clone the body of the function into the dest function.
|
|
|
|
SmallVector<ReturnInst*, 8> Returns; // Ignore returns.
|
2014-04-15 14:32:26 +08:00
|
|
|
CloneFunctionInto(Dst, Src, ValueMap, false, Returns, "", nullptr,
|
2013-05-28 23:17:05 +08:00
|
|
|
&TypeMap, &ValMaterializer);
|
2011-10-11 08:24:54 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +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);
|
2014-05-09 22:39:25 +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]);
|
2014-05-17 03:35:39 +08:00
|
|
|
Constant *Val =
|
|
|
|
MapValue(Aliasee, ValueMap, RF_None, &TypeMap, &ValMaterializer);
|
2014-06-03 10:41:57 +08:00
|
|
|
DA->setAliasee(Val);
|
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,
|
2013-05-28 23:17:05 +08:00
|
|
|
RF_None, &TypeMap, &ValMaterializer));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
|
|
|
|
/// linkModuleFlagsMetadata - Merge the linker flags in Src into the Dest
|
|
|
|
/// module.
|
|
|
|
bool ModuleLinker::linkModuleFlagsMetadata() {
|
2013-01-17 02:39:23 +08:00
|
|
|
// If the source module has no module flags, we are done.
|
2012-02-11 19:38:06 +08:00
|
|
|
const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
|
|
|
|
if (!SrcModFlags) return false;
|
|
|
|
|
|
|
|
// If the destination module doesn't have module flags yet, then just copy
|
|
|
|
// over the source module's flags.
|
2013-01-17 02:39:23 +08:00
|
|
|
NamedMDNode *DstModFlags = DstM->getOrInsertModuleFlagsMetadata();
|
2012-02-11 19:38:06 +08:00
|
|
|
if (DstModFlags->getNumOperands() == 0) {
|
|
|
|
for (unsigned I = 0, E = SrcModFlags->getNumOperands(); I != E; ++I)
|
|
|
|
DstModFlags->addOperand(SrcModFlags->getOperand(I));
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// First build a map of the existing module flags and requirements.
|
|
|
|
DenseMap<MDString*, MDNode*> Flags;
|
|
|
|
SmallSetVector<MDNode*, 16> Requirements;
|
|
|
|
for (unsigned I = 0, E = DstModFlags->getNumOperands(); I != E; ++I) {
|
|
|
|
MDNode *Op = DstModFlags->getOperand(I);
|
|
|
|
ConstantInt *Behavior = cast<ConstantInt>(Op->getOperand(0));
|
|
|
|
MDString *ID = cast<MDString>(Op->getOperand(1));
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
if (Behavior->getZExtValue() == Module::Require) {
|
|
|
|
Requirements.insert(cast<MDNode>(Op->getOperand(2)));
|
|
|
|
} else {
|
|
|
|
Flags[ID] = Op;
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// Merge in the flags from the source module, and also collect its set of
|
|
|
|
// requirements.
|
|
|
|
bool HasErr = false;
|
|
|
|
for (unsigned I = 0, E = SrcModFlags->getNumOperands(); I != E; ++I) {
|
|
|
|
MDNode *SrcOp = SrcModFlags->getOperand(I);
|
|
|
|
ConstantInt *SrcBehavior = cast<ConstantInt>(SrcOp->getOperand(0));
|
|
|
|
MDString *ID = cast<MDString>(SrcOp->getOperand(1));
|
|
|
|
MDNode *DstOp = Flags.lookup(ID);
|
|
|
|
unsigned SrcBehaviorValue = SrcBehavior->getZExtValue();
|
|
|
|
|
|
|
|
// If this is a requirement, add it and continue.
|
|
|
|
if (SrcBehaviorValue == Module::Require) {
|
|
|
|
// If the destination module does not already have this requirement, add
|
|
|
|
// it.
|
|
|
|
if (Requirements.insert(cast<MDNode>(SrcOp->getOperand(2)))) {
|
|
|
|
DstModFlags->addOperand(SrcOp);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there is no existing flag with this ID, just add it.
|
|
|
|
if (!DstOp) {
|
|
|
|
Flags[ID] = SrcOp;
|
|
|
|
DstModFlags->addOperand(SrcOp);
|
|
|
|
continue;
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// Otherwise, perform a merge.
|
|
|
|
ConstantInt *DstBehavior = cast<ConstantInt>(DstOp->getOperand(0));
|
|
|
|
unsigned DstBehaviorValue = DstBehavior->getZExtValue();
|
|
|
|
|
|
|
|
// If either flag has override behavior, handle it first.
|
|
|
|
if (DstBehaviorValue == Module::Override) {
|
|
|
|
// Diagnose inconsistent flags which both have override behavior.
|
|
|
|
if (SrcBehaviorValue == Module::Override &&
|
|
|
|
SrcOp->getOperand(2) != DstOp->getOperand(2)) {
|
|
|
|
HasErr |= emitError("linking module flags '" + ID->getString() +
|
|
|
|
"': IDs have conflicting override values");
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
} else if (SrcBehaviorValue == Module::Override) {
|
|
|
|
// Update the destination flag to that of the source.
|
|
|
|
DstOp->replaceOperandWith(0, SrcBehavior);
|
|
|
|
DstOp->replaceOperandWith(2, SrcOp->getOperand(2));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Diagnose inconsistent merge behavior types.
|
|
|
|
if (SrcBehaviorValue != DstBehaviorValue) {
|
|
|
|
HasErr |= emitError("linking module flags '" + ID->getString() +
|
|
|
|
"': IDs have conflicting behaviors");
|
|
|
|
continue;
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// Perform the merge for standard behavior types.
|
|
|
|
switch (SrcBehaviorValue) {
|
|
|
|
case Module::Require:
|
2014-06-18 13:05:13 +08:00
|
|
|
case Module::Override: llvm_unreachable("not possible");
|
2013-01-17 02:39:23 +08:00
|
|
|
case Module::Error: {
|
|
|
|
// Emit an error if the values differ.
|
|
|
|
if (SrcOp->getOperand(2) != DstOp->getOperand(2)) {
|
|
|
|
HasErr |= emitError("linking module flags '" + ID->getString() +
|
|
|
|
"': IDs have conflicting values");
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
case Module::Warning: {
|
|
|
|
// Emit a warning if the values differ.
|
|
|
|
if (SrcOp->getOperand(2) != DstOp->getOperand(2)) {
|
2014-02-07 02:01:56 +08:00
|
|
|
if (!SuppressWarnings) {
|
|
|
|
errs() << "WARNING: linking module flags '" << ID->getString()
|
|
|
|
<< "': IDs have conflicting values";
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
2013-01-17 02:39:23 +08:00
|
|
|
continue;
|
|
|
|
}
|
2013-01-17 05:38:56 +08:00
|
|
|
case Module::Append: {
|
|
|
|
MDNode *DstValue = cast<MDNode>(DstOp->getOperand(2));
|
|
|
|
MDNode *SrcValue = cast<MDNode>(SrcOp->getOperand(2));
|
|
|
|
unsigned NumOps = DstValue->getNumOperands() + SrcValue->getNumOperands();
|
|
|
|
Value **VP, **Values = VP = new Value*[NumOps];
|
|
|
|
for (unsigned i = 0, e = DstValue->getNumOperands(); i != e; ++i, ++VP)
|
|
|
|
*VP = DstValue->getOperand(i);
|
|
|
|
for (unsigned i = 0, e = SrcValue->getNumOperands(); i != e; ++i, ++VP)
|
|
|
|
*VP = SrcValue->getOperand(i);
|
|
|
|
DstOp->replaceOperandWith(2, MDNode::get(DstM->getContext(),
|
|
|
|
ArrayRef<Value*>(Values,
|
|
|
|
NumOps)));
|
|
|
|
delete[] Values;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Module::AppendUnique: {
|
|
|
|
SmallSetVector<Value*, 16> Elts;
|
|
|
|
MDNode *DstValue = cast<MDNode>(DstOp->getOperand(2));
|
|
|
|
MDNode *SrcValue = cast<MDNode>(SrcOp->getOperand(2));
|
|
|
|
for (unsigned i = 0, e = DstValue->getNumOperands(); i != e; ++i)
|
|
|
|
Elts.insert(DstValue->getOperand(i));
|
|
|
|
for (unsigned i = 0, e = SrcValue->getNumOperands(); i != e; ++i)
|
|
|
|
Elts.insert(SrcValue->getOperand(i));
|
|
|
|
DstOp->replaceOperandWith(2, MDNode::get(DstM->getContext(),
|
|
|
|
ArrayRef<Value*>(Elts.begin(),
|
|
|
|
Elts.end())));
|
|
|
|
break;
|
|
|
|
}
|
2013-01-17 02:39:23 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check all of the requirements.
|
|
|
|
for (unsigned I = 0, E = Requirements.size(); I != E; ++I) {
|
|
|
|
MDNode *Requirement = Requirements[I];
|
|
|
|
MDString *Flag = cast<MDString>(Requirement->getOperand(0));
|
|
|
|
Value *ReqValue = Requirement->getOperand(1);
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
MDNode *Op = Flags[Flag];
|
|
|
|
if (!Op || Op->getOperand(2) != ReqValue) {
|
|
|
|
HasErr |= emitError("linking module flags '" + Flag->getString() +
|
|
|
|
"': does not have the required value");
|
|
|
|
continue;
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return HasErr;
|
|
|
|
}
|
2014-05-09 22:39:25 +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 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.
|
2014-02-26 04:01:08 +08:00
|
|
|
if (!DstM->getDataLayout() && SrcM->getDataLayout())
|
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->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
|
|
|
|
2014-02-26 04:01:08 +08:00
|
|
|
if (SrcM->getDataLayout() && DstM->getDataLayout() &&
|
2014-02-27 01:02:08 +08:00
|
|
|
*SrcM->getDataLayout() != *DstM->getDataLayout()) {
|
2014-02-07 02:01:56 +08:00
|
|
|
if (!SuppressWarnings) {
|
2014-03-06 05:26:42 +08:00
|
|
|
errs() << "WARNING: Linking two modules of different data layouts: '"
|
|
|
|
<< SrcM->getModuleIdentifier() << "' is '"
|
|
|
|
<< SrcM->getDataLayoutStr() << "' whereas '"
|
|
|
|
<< DstM->getModuleIdentifier() << "' is '"
|
|
|
|
<< DstM->getDataLayoutStr() << "'\n";
|
2014-02-07 02:01:56 +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->getTargetTriple().empty() &&
|
|
|
|
DstM->getTargetTriple() != SrcM->getTargetTriple()) {
|
2014-02-07 02:01:56 +08:00
|
|
|
if (!SuppressWarnings) {
|
2014-03-06 05:26:42 +08:00
|
|
|
errs() << "WARNING: Linking two modules of different target triples: "
|
|
|
|
<< SrcM->getModuleIdentifier() << "' is '"
|
|
|
|
<< SrcM->getTargetTriple() << "' whereas '"
|
|
|
|
<< DstM->getModuleIdentifier() << "' is '"
|
2014-02-07 02:01:56 +08:00
|
|
|
<< 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
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
ComdatsChosen.clear();
|
|
|
|
for (const StringMapEntry<llvm::Comdat> &SMEC : SrcM->getComdatSymbolTable()) {
|
|
|
|
const Comdat &C = SMEC.getValue();
|
|
|
|
if (ComdatsChosen.count(&C))
|
|
|
|
continue;
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
bool LinkFromSrc;
|
|
|
|
if (getComdatResult(&C, SK, LinkFromSrc))
|
|
|
|
return true;
|
|
|
|
ComdatsChosen[&C] = std::make_pair(SK, LinkFromSrc);
|
|
|
|
}
|
|
|
|
|
2014-08-13 00:46:37 +08:00
|
|
|
// Upgrade mismatched global arrays.
|
|
|
|
upgradeMismatchedGlobals();
|
|
|
|
|
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]);
|
2014-05-09 22:39:25 +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
|
|
|
// 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;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2013-09-16 09:08:15 +08:00
|
|
|
Function *DF = cast<Function>(ValueMap[SF]);
|
|
|
|
if (SF->hasPrefixData()) {
|
|
|
|
// Link in the prefix data.
|
|
|
|
DF->setPrefixData(MapValue(
|
|
|
|
SF->getPrefixData(), ValueMap, RF_None, &TypeMap, &ValMaterializer));
|
|
|
|
}
|
|
|
|
|
2011-10-15 06:17:46 +08:00
|
|
|
// Skip if no body (function is external) or materialize.
|
|
|
|
if (SF->isDeclaration()) {
|
|
|
|
if (!SF->isMaterializable())
|
|
|
|
continue;
|
|
|
|
if (SF->Materialize(&ErrorMsg))
|
|
|
|
return true;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2013-09-16 09:08:15 +08:00
|
|
|
linkFunctionBody(DF, 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;
|
|
|
|
|
2014-01-16 14:29:36 +08:00
|
|
|
// Update the initializers in the DstM module now that all globals that may
|
|
|
|
// be referenced are in DstM.
|
|
|
|
linkGlobalInits();
|
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// Process vector of lazily linked in functions.
|
|
|
|
bool LinkedInAnyFunctions;
|
|
|
|
do {
|
|
|
|
LinkedInAnyFunctions = false;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2013-03-28 01:54:41 +08:00
|
|
|
for(std::vector<Function*>::iterator I = LazilyLinkFunctions.begin(),
|
2014-05-09 22:39:25 +08:00
|
|
|
E = LazilyLinkFunctions.end(); I != E; ++I) {
|
2013-03-28 01:54:41 +08:00
|
|
|
Function *SF = *I;
|
2013-05-28 23:17:05 +08:00
|
|
|
if (!SF)
|
|
|
|
continue;
|
|
|
|
|
2013-03-28 01:54:41 +08:00
|
|
|
Function *DF = cast<Function>(ValueMap[SF]);
|
2013-09-16 09:08:15 +08:00
|
|
|
if (SF->hasPrefixData()) {
|
|
|
|
// Link in the prefix data.
|
|
|
|
DF->setPrefixData(MapValue(SF->getPrefixData(),
|
|
|
|
ValueMap,
|
|
|
|
RF_None,
|
|
|
|
&TypeMap,
|
|
|
|
&ValMaterializer));
|
|
|
|
}
|
2012-03-23 15:22:49 +08:00
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
// Materialize if necessary.
|
|
|
|
if (SF->isDeclaration()) {
|
|
|
|
if (!SF->isMaterializable())
|
|
|
|
continue;
|
|
|
|
if (SF->Materialize(&ErrorMsg))
|
|
|
|
return true;
|
2011-11-02 08:24:56 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
// Erase from vector *before* the function body is linked - linkFunctionBody could
|
|
|
|
// invalidate I.
|
|
|
|
LazilyLinkFunctions.erase(I);
|
|
|
|
|
|
|
|
// Link in function body.
|
|
|
|
linkFunctionBody(DF, SF);
|
|
|
|
SF->Dematerialize();
|
|
|
|
|
|
|
|
// Set flag to indicate we may have more functions to lazily link in
|
|
|
|
// since we linked in a function.
|
|
|
|
LinkedInAnyFunctions = true;
|
|
|
|
break;
|
2011-11-02 08:24:56 +08:00
|
|
|
}
|
|
|
|
} while (LinkedInAnyFunctions);
|
2014-05-09 22:39:25 +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 all of the types from the source are used, resolve any structs
|
|
|
|
// copied over to the dest that didn't exist there.
|
|
|
|
TypeMap.linkDefinedTypeBodies();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2004-11-13 04:37:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-02-21 06:19:24 +08:00
|
|
|
Linker::Linker(Module *M, bool SuppressWarnings)
|
|
|
|
: Composite(M), SuppressWarnings(SuppressWarnings) {
|
2013-05-04 13:05:18 +08:00
|
|
|
TypeFinder StructTypes;
|
|
|
|
StructTypes.run(*M, true);
|
|
|
|
IdentifiedStructTypes.insert(StructTypes.begin(), StructTypes.end());
|
|
|
|
}
|
2013-05-04 11:48:37 +08:00
|
|
|
|
|
|
|
Linker::~Linker() {
|
|
|
|
}
|
|
|
|
|
2013-10-16 16:59:57 +08:00
|
|
|
void Linker::deleteModule() {
|
|
|
|
delete Composite;
|
2014-04-15 14:32:26 +08:00
|
|
|
Composite = nullptr;
|
2013-10-16 16:59:57 +08:00
|
|
|
}
|
|
|
|
|
2013-05-04 11:48:37 +08:00
|
|
|
bool Linker::linkInModule(Module *Src, unsigned Mode, std::string *ErrorMsg) {
|
2014-02-21 06:19:24 +08:00
|
|
|
ModuleLinker TheLinker(Composite, IdentifiedStructTypes, Src, Mode,
|
|
|
|
SuppressWarnings);
|
2013-05-04 12:08:02 +08:00
|
|
|
if (TheLinker.run()) {
|
|
|
|
if (ErrorMsg)
|
|
|
|
*ErrorMsg = TheLinker.ErrorMsg;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2013-05-04 11:48:37 +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
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// LinkModules entrypoint.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2012-03-23 04:28:27 +08:00
|
|
|
/// LinkModules - This function links two modules together, with the resulting
|
2013-03-09 06:29:44 +08:00
|
|
|
/// Dest module modified to be the composite of the two input modules. If an
|
2012-03-23 04:28:27 +08:00
|
|
|
/// 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.
|
2014-05-09 22:39:25 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src, unsigned Mode,
|
2011-10-11 08:24:54 +08:00
|
|
|
std::string *ErrorMsg) {
|
2013-05-04 12:08:02 +08:00
|
|
|
Linker L(Dest);
|
|
|
|
return L.linkInModule(Src, Mode, ErrorMsg);
|
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
|
|
|
}
|
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),
|
2014-04-15 14:32:26 +08:00
|
|
|
Mode, OutMessages? &Messages : nullptr);
|
2012-05-09 16:55:40 +08:00
|
|
|
if (OutMessages)
|
|
|
|
*OutMessages = strdup(Messages.c_str());
|
|
|
|
return Result;
|
|
|
|
}
|