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"
|
2014-10-25 12:06:10 +08:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#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 {
|
2014-10-27 10:35:46 +08:00
|
|
|
typedef SmallPtrSet<StructType *, 32> TypeSet;
|
2013-05-04 13:05: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
|
|
|
class TypeMapTy : public ValueMapTypeRemapper {
|
2014-10-27 10:35:46 +08:00
|
|
|
/// This is a mapping from a source type to a destination type to use.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
DenseMap<Type*, Type*> MappedTypes;
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// 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.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
SmallVector<Type*, 16> SpeculativeTypes;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-29 00:41:24 +08:00
|
|
|
SmallVector<StructType*, 16> SpeculativeDstOpaqueTypes;
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// This is a list of non-opaque structs in the source module that are mapped
|
|
|
|
/// to an opaque struct in the destination module.
|
2011-12-20 08:03:52 +08:00
|
|
|
SmallVector<StructType*, 16> SrcDefinitionsToResolve;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// This is the set of opaque types in the destination modules who are
|
|
|
|
/// getting a body from the source module.
|
2011-12-20 08:03:52 +08:00
|
|
|
SmallPtrSet<StructType*, 16> DstResolvedOpaqueTypes;
|
2012-03-23 04:30:41 +08:00
|
|
|
|
2008-06-17 07:06:51 +08:00
|
|
|
public:
|
2014-12-02 00:32:20 +08:00
|
|
|
TypeMapTy(TypeSet &Set) : DstStructTypesSet(Set) {}
|
2013-05-04 13:05:18 +08:00
|
|
|
|
2014-12-02 00:32:20 +08:00
|
|
|
TypeSet &DstStructTypesSet;
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Indicate that the specified type in the destination module is conceptually
|
|
|
|
/// equivalent to the specified type in the source 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 addTypeMapping(Type *DstTy, Type *SrcTy);
|
|
|
|
|
2014-11-25 12:28:31 +08:00
|
|
|
/// Produce a body for an opaque type in the dest module from a type
|
|
|
|
/// definition in the source 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 linkDefinedTypeBodies();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Return the mapped type to use for the specified input type from the
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
/// source module.
|
|
|
|
Type *get(Type *SrcTy);
|
|
|
|
|
2014-11-25 22:35:53 +08:00
|
|
|
FunctionType *get(FunctionType *T) {
|
|
|
|
return cast<FunctionType>(get((Type *)T));
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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-10-27 10:35:46 +08:00
|
|
|
/// Dump out the type map for debugging purposes.
|
2012-03-23 04:28:27 +08:00
|
|
|
void dump() const {
|
2014-11-25 14:16:27 +08:00
|
|
|
for (auto &Pair : MappedTypes) {
|
2012-03-23 04:28:27 +08:00
|
|
|
dbgs() << "TypeMap: ";
|
2014-11-25 14:16:27 +08:00
|
|
|
Pair.first->print(dbgs());
|
2012-03-23 04:28:27 +08:00
|
|
|
dbgs() << " => ";
|
2014-11-25 14:16:27 +08:00
|
|
|
Pair.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:
|
2014-11-25 22:35:53 +08:00
|
|
|
Type *remapType(Type *SrcTy) override { return get(SrcTy); }
|
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) {
|
2014-11-29 00:26:14 +08:00
|
|
|
assert(SpeculativeTypes.empty());
|
2014-11-29 00:41:24 +08:00
|
|
|
assert(SpeculativeDstOpaqueTypes.empty());
|
2014-11-29 00:26:14 +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.
|
2014-11-28 01:01:10 +08:00
|
|
|
if (!areTypesIsomorphic(DstTy, SrcTy)) {
|
|
|
|
// Oops, they aren't isomorphic. Just discard this request by rolling out
|
|
|
|
// any speculative mappings we've established.
|
2014-11-29 00:26:14 +08:00
|
|
|
for (Type *Ty : SpeculativeTypes)
|
|
|
|
MappedTypes.erase(Ty);
|
2014-11-29 00:41:24 +08:00
|
|
|
|
|
|
|
SrcDefinitionsToResolve.resize(SrcDefinitionsToResolve.size() -
|
|
|
|
SpeculativeDstOpaqueTypes.size());
|
|
|
|
for (StructType *Ty : SpeculativeDstOpaqueTypes)
|
|
|
|
DstResolvedOpaqueTypes.erase(Ty);
|
2014-12-01 12:15:59 +08:00
|
|
|
} else {
|
|
|
|
for (Type *Ty : SpeculativeTypes)
|
|
|
|
if (auto *STy = dyn_cast<StructType>(Ty))
|
|
|
|
if (STy->hasName())
|
|
|
|
STy->setName("");
|
2014-11-25 13:59:24 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
SpeculativeTypes.clear();
|
2014-11-29 00:41:24 +08:00
|
|
|
SpeculativeDstOpaqueTypes.clear();
|
2008-06-17 05:00:18 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Recursively walk this pair of types, returning true if they are isomorphic,
|
|
|
|
/// false if they are 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 TypeMapTy::areTypesIsomorphic(Type *DstTy, Type *SrcTy) {
|
|
|
|
// Two types with differing kinds are clearly not isomorphic.
|
2014-11-25 22:35:53 +08:00
|
|
|
if (DstTy->getTypeID() != SrcTy->getTypeID())
|
|
|
|
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 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
|
2014-11-29 00:41:24 +08:00
|
|
|
// the dest, but fill it in later. 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.
|
2014-11-19 15:49:26 +08:00
|
|
|
if (!DstResolvedOpaqueTypes.insert(cast<StructType>(DstTy)).second)
|
2011-12-20 08:03:52 +08:00
|
|
|
return false;
|
|
|
|
SrcDefinitionsToResolve.push_back(SSTy);
|
2014-11-29 00:41:24 +08:00
|
|
|
SpeculativeTypes.push_back(SrcTy);
|
|
|
|
SpeculativeDstOpaqueTypes.push_back(cast<StructType>(DstTy));
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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);
|
|
|
|
|
2014-11-25 22:35:53 +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
|
|
|
void TypeMapTy::linkDefinedTypeBodies() {
|
|
|
|
SmallVector<Type*, 16> Elements;
|
2014-11-25 23:33:40 +08:00
|
|
|
for (StructType *SrcSTy : SrcDefinitionsToResolve) {
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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-11-25 23:33:40 +08:00
|
|
|
assert(DstSTy->isOpaque());
|
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());
|
2014-11-25 22:35:53 +08:00
|
|
|
for (unsigned I = 0, E = Elements.size(); I != E; ++I)
|
2014-11-25 23:33:40 +08:00
|
|
|
Elements[I] = get(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());
|
2005-04-22 06:55:34 +08:00
|
|
|
}
|
2014-11-25 23:33:40 +08:00
|
|
|
SrcDefinitionsToResolve.clear();
|
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
|
|
|
Type *TypeMapTy::get(Type *Ty) {
|
2014-12-02 00:32:20 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
for (auto &Pair : MappedTypes) {
|
|
|
|
assert(!(Pair.first != Ty && Pair.second == Ty) &&
|
|
|
|
"mapping to a source type");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 already have an entry for this type, return it.
|
|
|
|
Type **Entry = &MappedTypes[Ty];
|
2014-11-25 22:35:53 +08:00
|
|
|
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());
|
2014-11-25 22:35:53 +08:00
|
|
|
for (unsigned I = 0, E = Ty->getNumContainedTypes(); I != E; ++I) {
|
2014-11-25 23:33:40 +08:00
|
|
|
ElementTypes[I] = get(Ty->getContainedType(I));
|
2014-11-25 22:35:53 +08:00
|
|
|
AnyChange |= ElementTypes[I] != Ty->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
|
|
|
}
|
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];
|
2014-11-25 22:35:53 +08:00
|
|
|
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()) {
|
2014-11-25 22:35:53 +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:
|
2014-11-25 22:35:53 +08:00
|
|
|
return *Entry = PointerType::get(
|
|
|
|
ElementTypes[0], cast<PointerType>(Ty)->getAddressSpace());
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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::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.
|
2014-12-02 00:32:20 +08:00
|
|
|
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
|
|
|
|
2014-11-25 23:33:40 +08:00
|
|
|
// Otherwise we create a new type.
|
2011-12-20 08:03:52 +08:00
|
|
|
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.
|
2014-12-02 00:32:20 +08:00
|
|
|
DstStructTypesSet.insert(DTy);
|
2014-11-25 23:33:40 +08:00
|
|
|
*Entry = DTy;
|
|
|
|
|
|
|
|
SmallVector<Type*, 4> ElementTypes;
|
|
|
|
ElementTypes.resize(STy->getNumElements());
|
|
|
|
for (unsigned I = 0, E = ElementTypes.size(); I != E; ++I)
|
|
|
|
ElementTypes[I] = get(STy->getElementType(I));
|
|
|
|
DTy->setBody(ElementTypes, STy->isPacked());
|
|
|
|
|
|
|
|
// Steal STy's name.
|
|
|
|
if (STy->hasName()) {
|
|
|
|
SmallString<16> TmpName = STy->getName();
|
|
|
|
STy->setName("");
|
|
|
|
DTy->setName(TmpName);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 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 {
|
2014-11-25 14:11:24 +08:00
|
|
|
class ModuleLinker;
|
2013-05-28 23:17:05 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
/// 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;
|
2014-10-25 12:06:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
|
|
|
ValueMaterializerTy(TypeMapTy &TypeMap, Module *DstM,
|
|
|
|
std::vector<Function *> &LazilyLinkFunctions)
|
|
|
|
: ValueMaterializer(), TypeMap(TypeMap), DstM(DstM),
|
|
|
|
LazilyLinkFunctions(LazilyLinkFunctions) {}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
Value *materializeValueFor(Value *V) 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
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
class LinkDiagnosticInfo : public DiagnosticInfo {
|
|
|
|
const Twine &Msg;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
|
|
|
LinkDiagnosticInfo(DiagnosticSeverity Severity, const Twine &Msg);
|
|
|
|
void print(DiagnosticPrinter &DP) const override;
|
|
|
|
};
|
|
|
|
LinkDiagnosticInfo::LinkDiagnosticInfo(DiagnosticSeverity Severity,
|
|
|
|
const Twine &Msg)
|
|
|
|
: DiagnosticInfo(DK_Linker, Severity), Msg(Msg) {}
|
|
|
|
void LinkDiagnosticInfo::print(DiagnosticPrinter &DP) const { DP << Msg; }
|
|
|
|
|
|
|
|
/// This is an implementation class for the LinkModules function, which is the
|
|
|
|
/// entrypoint for this file.
|
|
|
|
class ModuleLinker {
|
|
|
|
Module *DstM, *SrcM;
|
|
|
|
|
|
|
|
TypeMapTy TypeMap;
|
|
|
|
ValueMaterializerTy ValMaterializer;
|
|
|
|
|
|
|
|
/// Mapping of values from what they used to be in Src, to what they are now
|
|
|
|
/// in DstM. ValueToValueMapTy is a ValueMap, which involves some overhead
|
|
|
|
/// due to the use of Value handles which the Linker doesn't actually need,
|
|
|
|
/// but this allows us to reuse the ValueMapper code.
|
|
|
|
ValueToValueMapTy ValueMap;
|
|
|
|
|
|
|
|
struct AppendingVarInfo {
|
|
|
|
GlobalVariable *NewGV; // New aggregate global in dest module.
|
|
|
|
const Constant *DstInit; // Old initializer from dest module.
|
|
|
|
const Constant *SrcInit; // Old initializer from src module.
|
|
|
|
};
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
std::vector<AppendingVarInfo> AppendingVars;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
// Set of items not to link in from source.
|
|
|
|
SmallPtrSet<const Value *, 16> DoNotLinkFromSource;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
// Vector of functions to lazily link in.
|
|
|
|
std::vector<Function *> LazilyLinkFunctions;
|
2014-02-21 06:19:24 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
Linker::DiagnosticHandlerFunction DiagnosticHandler;
|
2014-10-28 07:02:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
2014-12-02 00:32:20 +08:00
|
|
|
ModuleLinker(Module *dstM, TypeSet &Set, Module *srcM,
|
2014-11-25 14:11:24 +08:00
|
|
|
Linker::DiagnosticHandlerFunction DiagnosticHandler)
|
2014-12-02 00:32:20 +08:00
|
|
|
: DstM(dstM), SrcM(srcM), TypeMap(Set),
|
2014-11-25 14:11:24 +08:00
|
|
|
ValMaterializer(TypeMap, DstM, LazilyLinkFunctions),
|
|
|
|
DiagnosticHandler(DiagnosticHandler) {}
|
2014-02-21 06:19:24 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
bool run();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
private:
|
|
|
|
bool shouldLinkFromSource(bool &LinkFromSrc, const GlobalValue &Dest,
|
|
|
|
const GlobalValue &Src);
|
2014-09-09 23:21:00 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
/// Helper method for setting a message and returning an error code.
|
|
|
|
bool emitError(const Twine &Message) {
|
|
|
|
DiagnosticHandler(LinkDiagnosticInfo(DS_Error, Message));
|
|
|
|
return true;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void emitWarning(const Twine &Message) {
|
|
|
|
DiagnosticHandler(LinkDiagnosticInfo(DS_Warning, Message));
|
|
|
|
}
|
2014-10-25 12:06:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +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);
|
|
|
|
|
|
|
|
/// Given a global in the source module, return the global in the
|
|
|
|
/// destination module that is being linked to, if any.
|
|
|
|
GlobalValue *getLinkedToGlobal(const GlobalValue *SrcGV) {
|
|
|
|
// If the source has no name it can't link. If it has local linkage,
|
|
|
|
// there is no name match-up going on.
|
|
|
|
if (!SrcGV->hasName() || SrcGV->hasLocalLinkage())
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Otherwise see if we have a match in the destination module's symtab.
|
|
|
|
GlobalValue *DGV = DstM->getNamedValue(SrcGV->getName());
|
|
|
|
if (!DGV)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// If we found a global with the same name in the dest module, but it has
|
|
|
|
// internal linkage, we are really not doing any linkage here.
|
|
|
|
if (DGV->hasLocalLinkage())
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Otherwise, we do in fact link to the destination global.
|
|
|
|
return DGV;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void computeTypeMapping();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void upgradeMismatchedGlobalArray(StringRef Name);
|
|
|
|
void upgradeMismatchedGlobals();
|
2014-08-13 00:46:37 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
bool linkAppendingVarProto(GlobalVariable *DstGV,
|
|
|
|
const GlobalVariable *SrcGV);
|
2014-11-02 21:28:57 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
bool linkGlobalValueProto(GlobalValue *GV);
|
|
|
|
GlobalValue *linkGlobalVariableProto(const GlobalVariable *SGVar,
|
|
|
|
GlobalValue *DGV, bool LinkFromSrc);
|
|
|
|
GlobalValue *linkFunctionProto(const Function *SF, GlobalValue *DGV,
|
|
|
|
bool LinkFromSrc);
|
|
|
|
GlobalValue *linkGlobalAliasProto(const GlobalAlias *SGA, GlobalValue *DGV,
|
|
|
|
bool LinkFromSrc);
|
2014-11-02 21:28:57 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
bool linkModuleFlagsMetadata();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11: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
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// The LLVM SymbolTable class autorenames globals that conflict 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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// copy additional attributes (those not needed to construct 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-10-25 12:06:10 +08:00
|
|
|
bool ModuleLinker::shouldLinkFromSource(bool &LinkFromSrc,
|
|
|
|
const GlobalValue &Dest,
|
2014-09-09 23:21:00 +08:00
|
|
|
const GlobalValue &Src) {
|
2014-11-02 21:28:57 +08:00
|
|
|
// We always have to add Src if it has appending linkage.
|
|
|
|
if (Src.hasAppendingLinkage()) {
|
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-10-25 02:13:04 +08:00
|
|
|
bool SrcIsDeclaration = Src.isDeclarationForLinker();
|
|
|
|
bool DestIsDeclaration = Dest.isDeclarationForLinker();
|
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.
|
2014-10-25 12:06:10 +08:00
|
|
|
if (Src.hasDLLImportStorageClass()) {
|
2014-09-09 23:21:00 +08:00
|
|
|
// If one of GVs is marked as DLLImport, result should be dllimport'ed.
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = DestIsDeclaration;
|
|
|
|
return false;
|
|
|
|
}
|
2014-09-09 23:21:00 +08:00
|
|
|
// If the Dest is weak, use the source linkage.
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = Dest.hasExternalWeakLinkage();
|
|
|
|
return false;
|
2014-09-09 23:21:00 +08:00
|
|
|
}
|
|
|
|
|
2014-10-25 12:06:10 +08:00
|
|
|
if (DestIsDeclaration) {
|
2014-09-09 23:21:00 +08:00
|
|
|
// If Dest is external but Src is not:
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
|
|
|
}
|
2014-09-09 23:21:00 +08:00
|
|
|
|
2014-09-09 23:59:12 +08:00
|
|
|
if (Src.hasCommonLinkage()) {
|
2014-10-25 12:06:10 +08:00
|
|
|
if (Dest.hasLinkOnceLinkage() || Dest.hasWeakLinkage()) {
|
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
|
|
|
}
|
2014-09-09 23:59:12 +08:00
|
|
|
|
2014-10-25 12:06:10 +08:00
|
|
|
if (!Dest.hasCommonLinkage()) {
|
|
|
|
LinkFromSrc = false;
|
2014-09-09 23:59:12 +08:00
|
|
|
return false;
|
2014-10-25 12:06:10 +08:00
|
|
|
}
|
2014-09-09 23:59:12 +08:00
|
|
|
|
2014-10-31 12:46:38 +08:00
|
|
|
// FIXME: Make datalayout mandatory and just use getDataLayout().
|
|
|
|
DataLayout DL(Dest.getParent());
|
|
|
|
|
2014-09-09 23:59:12 +08:00
|
|
|
uint64_t DestSize = DL.getTypeAllocSize(Dest.getType()->getElementType());
|
|
|
|
uint64_t SrcSize = DL.getTypeAllocSize(Src.getType()->getElementType());
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = SrcSize > DestSize;
|
|
|
|
return false;
|
2014-09-09 23:59:12 +08:00
|
|
|
}
|
|
|
|
|
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-10-25 12:06:10 +08:00
|
|
|
if (Dest.hasLinkOnceLinkage() && Src.hasWeakLinkage()) {
|
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
|
|
|
}
|
2014-09-09 23:21:00 +08:00
|
|
|
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = false;
|
2014-09-09 23:59:12 +08:00
|
|
|
return false;
|
2014-09-09 23:21:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (Dest.isWeakForLinker()) {
|
|
|
|
assert(Src.hasExternalLinkage());
|
2014-10-25 12:06:10 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
2014-09-09 23:21:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
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-10-27 10:35:46 +08:00
|
|
|
/// 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.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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::computeTypeMapping() {
|
2014-11-25 12:26:19 +08:00
|
|
|
for (GlobalValue &SGV : SrcM->globals()) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(&SGV);
|
|
|
|
if (!DGV)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!DGV->hasAppendingLinkage() || !SGV.hasAppendingLinkage()) {
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), SGV.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());
|
2014-11-25 12:26:19 +08:00
|
|
|
ArrayType *SAT = cast<ArrayType>(SGV.getType()->getElementType());
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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.addTypeMapping(DAT->getElementType(), SAT->getElementType());
|
2009-08-12 02:01:24 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 12:26:19 +08:00
|
|
|
for (GlobalValue &SGV : *SrcM) {
|
|
|
|
if (GlobalValue *DGV = getLinkedToGlobal(&SGV))
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), SGV.getType());
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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-02-28 06:34:19 +08:00
|
|
|
|
2014-11-25 12:43:59 +08:00
|
|
|
for (GlobalValue &SGV : SrcM->aliases()) {
|
|
|
|
if (GlobalValue *DGV = getLinkedToGlobal(&SGV))
|
|
|
|
TypeMap.addTypeMapping(DGV->getType(), SGV.getType());
|
|
|
|
}
|
|
|
|
|
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);
|
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.
|
2014-12-02 02:42:18 +08:00
|
|
|
if (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
|
|
|
// 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");
|
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// If there were any appending global variables, link them together now.
|
|
|
|
/// Return true on error.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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::linkAppendingVarProto(GlobalVariable *DstGV,
|
2014-11-01 00:08:17 +08:00
|
|
|
const 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
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
bool ModuleLinker::linkGlobalValueProto(GlobalValue *SGV) {
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
GlobalValue *DGV = getLinkedToGlobal(SGV);
|
2014-11-02 21:28:57 +08:00
|
|
|
|
|
|
|
// Handle the ultra special appending linkage case first.
|
|
|
|
if (DGV && DGV->hasAppendingLinkage())
|
|
|
|
return linkAppendingVarProto(cast<GlobalVariable>(DGV),
|
|
|
|
cast<GlobalVariable>(SGV));
|
|
|
|
|
|
|
|
bool LinkFromSrc = true;
|
|
|
|
Comdat *C = nullptr;
|
|
|
|
GlobalValue::VisibilityTypes Visibility = SGV->getVisibility();
|
2013-09-04 22:05:09 +08:00
|
|
|
bool HasUnnamedAddr = SGV->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 (const Comdat *SC = SGV->getComdat()) {
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
std::tie(SK, LinkFromSrc) = ComdatsChosen[SC];
|
2014-11-02 21:28:57 +08:00
|
|
|
C = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
C->setSelectionKind(SK);
|
|
|
|
} else if (DGV) {
|
|
|
|
if (shouldLinkFromSource(LinkFromSrc, *DGV, *SGV))
|
|
|
|
return true;
|
2014-06-28 02:19:56 +08:00
|
|
|
}
|
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (!LinkFromSrc) {
|
|
|
|
// Track the source global so that we don't attempt to copy it over when
|
|
|
|
// processing global initializers.
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (DGV)
|
2008-07-14 15:23:24 +08:00
|
|
|
// Make sure to remember this mapping.
|
2014-11-02 21:28:57 +08:00
|
|
|
ValueMap[SGV] =
|
|
|
|
ConstantExpr::getBitCast(DGV, TypeMap.get(SGV->getType()));
|
|
|
|
}
|
2014-11-02 17:10:31 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (DGV) {
|
|
|
|
Visibility = isLessConstraining(Visibility, DGV->getVisibility())
|
|
|
|
? DGV->getVisibility()
|
|
|
|
: Visibility;
|
|
|
|
HasUnnamedAddr = HasUnnamedAddr && DGV->hasUnnamedAddr();
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (!LinkFromSrc && !DGV)
|
2014-06-28 02:19:56 +08:00
|
|
|
return false;
|
2014-11-02 21:28:57 +08:00
|
|
|
|
|
|
|
GlobalValue *NewGV;
|
|
|
|
if (auto *SGVar = dyn_cast<GlobalVariable>(SGV)) {
|
|
|
|
NewGV = linkGlobalVariableProto(SGVar, DGV, LinkFromSrc);
|
|
|
|
if (!NewGV)
|
|
|
|
return true;
|
|
|
|
} else if (auto *SF = dyn_cast<Function>(SGV)) {
|
|
|
|
NewGV = linkFunctionProto(SF, DGV, LinkFromSrc);
|
|
|
|
} else {
|
|
|
|
NewGV = linkGlobalAliasProto(cast<GlobalAlias>(SGV), DGV, LinkFromSrc);
|
2014-06-28 02:19:56 +08:00
|
|
|
}
|
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (NewGV) {
|
|
|
|
if (NewGV != DGV)
|
|
|
|
copyGVAttributes(NewGV, SGV);
|
2014-06-28 02:19:56 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
NewGV->setUnnamedAddr(HasUnnamedAddr);
|
|
|
|
NewGV->setVisibility(Visibility);
|
2014-11-01 07:10:07 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (auto *NewGO = dyn_cast<GlobalObject>(NewGV)) {
|
|
|
|
if (C)
|
|
|
|
NewGO->setComdat(C);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make sure to remember this mapping.
|
|
|
|
if (NewGV != DGV) {
|
|
|
|
if (DGV) {
|
|
|
|
DGV->replaceAllUsesWith(
|
|
|
|
ConstantExpr::getBitCast(NewGV, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
|
|
|
}
|
|
|
|
ValueMap[SGV] = NewGV;
|
|
|
|
}
|
2008-03-06 06:22:46 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2007-06-29 03:02:54 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
/// Loop through the global variables in the src module and merge them into the
|
|
|
|
/// dest module.
|
|
|
|
GlobalValue *ModuleLinker::linkGlobalVariableProto(const GlobalVariable *SGVar,
|
|
|
|
GlobalValue *DGV,
|
|
|
|
bool LinkFromSrc) {
|
|
|
|
unsigned Alignment = 0;
|
|
|
|
bool ClearConstant = false;
|
2014-06-28 02:19: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 (DGV) {
|
2014-11-02 21:28:57 +08:00
|
|
|
if (DGV->hasCommonLinkage() && SGVar->hasCommonLinkage())
|
|
|
|
Alignment = std::max(SGVar->getAlignment(), DGV->getAlignment());
|
2012-01-06 07:02:01 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
auto *DGVar = dyn_cast<GlobalVariable>(DGV);
|
|
|
|
if (!SGVar->isConstant() || (DGVar && !DGVar->isConstant()))
|
|
|
|
ClearConstant = true;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
if (!LinkFromSrc) {
|
|
|
|
if (auto *NewGVar = dyn_cast<GlobalVariable>(DGV)) {
|
|
|
|
if (Alignment)
|
|
|
|
NewGVar->setAlignment(Alignment);
|
|
|
|
if (NewGVar->isDeclaration() && ClearConstant)
|
|
|
|
NewGVar->setConstant(false);
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2014-11-02 21:28:57 +08:00
|
|
|
return DGV;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-02 21:28:57 +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(SGVar->getType()->getElementType()),
|
|
|
|
SGVar->isConstant(), SGVar->getLinkage(), /*init*/ nullptr,
|
|
|
|
SGVar->getName(), /*insertbefore*/ nullptr, SGVar->getThreadLocalMode(),
|
|
|
|
SGVar->getType()->getAddressSpace());
|
|
|
|
|
|
|
|
if (Alignment)
|
|
|
|
NewDGV->setAlignment(Alignment);
|
|
|
|
|
|
|
|
return NewDGV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Link the function in the source module into the destination module if
|
|
|
|
/// needed, setting up mapping information.
|
|
|
|
GlobalValue *ModuleLinker::linkFunctionProto(const Function *SF,
|
|
|
|
GlobalValue *DGV,
|
|
|
|
bool LinkFromSrc) {
|
|
|
|
if (!LinkFromSrc)
|
|
|
|
return DGV;
|
|
|
|
|
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);
|
2014-11-02 21:28:57 +08:00
|
|
|
return nullptr;
|
2014-06-28 02:19: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 there is no linkage to be performed or we are linking from the source,
|
|
|
|
// bring SF over.
|
2014-11-02 21:28:57 +08:00
|
|
|
return Function::Create(TypeMap.get(SF->getFunctionType()), SF->getLinkage(),
|
|
|
|
SF->getName(), DstM);
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Set up prototypes for any aliases that come over from the source module.
|
2014-11-02 21:28:57 +08:00
|
|
|
GlobalValue *ModuleLinker::linkGlobalAliasProto(const GlobalAlias *SGA,
|
|
|
|
GlobalValue *DGV,
|
|
|
|
bool LinkFromSrc) {
|
|
|
|
if (!LinkFromSrc)
|
|
|
|
return DGV;
|
2014-06-28 02:19: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 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-11-02 21:28:57 +08:00
|
|
|
return GlobalAlias::create(PTy->getElementType(), PTy->getAddressSpace(),
|
|
|
|
SGA->getLinkage(), SGA->getName(), DstM);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
2014-11-01 00:08:17 +08:00
|
|
|
static void getArrayElements(const 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
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// 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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// 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
|
|
|
}
|
|
|
|
|
2014-10-28 08:24:16 +08:00
|
|
|
// 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
|
|
|
|
2014-10-28 08:24:16 +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)
|
|
|
|
RemapInstruction(I, ValueMap, RF_IgnoreMissingEntries, &TypeMap,
|
|
|
|
&ValMaterializer);
|
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
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// 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
|
|
|
}
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Insert all of the named MDNodes 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::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
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Merge the linker flags in Src into the Dest module.
|
2012-02-11 19:38:06 +08:00
|
|
|
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) {
|
2014-11-12 05:30:22 +08:00
|
|
|
MDNode *Op = DstModFlags->getOperand(I);
|
2013-01-17 02:39:23 +08:00
|
|
|
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) {
|
2014-11-12 05:30:22 +08:00
|
|
|
MDNode *SrcOp = SrcModFlags->getOperand(I);
|
2013-01-17 02:39:23 +08:00
|
|
|
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-10-25 12:06:10 +08:00
|
|
|
emitWarning("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-10-25 12:06:10 +08:00
|
|
|
emitWarning("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-10-25 12:06:10 +08:00
|
|
|
emitWarning("Linking two modules of different target triples: " +
|
|
|
|
SrcM->getModuleIdentifier() + "' is '" +
|
|
|
|
SrcM->getTargetTriple() + "' whereas '" +
|
|
|
|
DstM->getModuleIdentifier() + "' is '" +
|
|
|
|
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();
|
2014-11-19 13:49:42 +08:00
|
|
|
for (const auto &SMEC : SrcM->getComdatSymbolTable()) {
|
2014-06-28 02:19:56 +08:00
|
|
|
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)
|
2014-11-02 21:28:57 +08:00
|
|
|
if (linkGlobalValueProto(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 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)
|
2014-11-02 21:28:57 +08:00
|
|
|
if (linkGlobalValueProto(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 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)
|
2014-11-02 21:28:57 +08:00
|
|
|
if (linkGlobalValueProto(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 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));
|
|
|
|
}
|
|
|
|
|
2014-10-25 02:13:04 +08:00
|
|
|
// Materialize if needed.
|
2014-11-02 00:46:18 +08:00
|
|
|
if (std::error_code EC = SF->materialize())
|
|
|
|
return emitError(EC.message());
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-10-25 02:13:04 +08:00
|
|
|
// Skip if no body (function is external).
|
|
|
|
if (SF->isDeclaration())
|
|
|
|
continue;
|
|
|
|
|
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
|
|
|
|
2014-10-25 02:13:04 +08:00
|
|
|
// Materialize if needed.
|
2014-11-02 00:46:18 +08:00
|
|
|
if (std::error_code EC = SF->materialize())
|
|
|
|
return emitError(EC.message());
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-10-25 02:13:04 +08:00
|
|
|
// Skip if no body (function is external).
|
|
|
|
if (SF->isDeclaration())
|
|
|
|
continue;
|
|
|
|
|
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
|
|
|
|
2004-11-13 04:37:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-18 04:51:01 +08:00
|
|
|
void Linker::init(Module *M, DiagnosticHandlerFunction DiagnosticHandler) {
|
|
|
|
this->Composite = M;
|
|
|
|
this->DiagnosticHandler = DiagnosticHandler;
|
2014-12-02 00:32:20 +08:00
|
|
|
|
|
|
|
TypeFinder StructTypes;
|
|
|
|
StructTypes.run(*M, true);
|
|
|
|
IdentifiedStructTypes.insert(StructTypes.begin(), StructTypes.end());
|
2013-05-04 13:05:18 +08:00
|
|
|
}
|
2013-05-04 11:48:37 +08:00
|
|
|
|
2014-11-18 04:51:01 +08:00
|
|
|
Linker::Linker(Module *M, DiagnosticHandlerFunction DiagnosticHandler) {
|
|
|
|
init(M, DiagnosticHandler);
|
|
|
|
}
|
|
|
|
|
|
|
|
Linker::Linker(Module *M) {
|
|
|
|
init(M, [this](const DiagnosticInfo &DI) {
|
|
|
|
Composite->getContext().diagnose(DI);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2014-10-28 08:24:16 +08:00
|
|
|
bool Linker::linkInModule(Module *Src) {
|
2014-12-02 00:32:20 +08:00
|
|
|
ModuleLinker TheLinker(Composite, IdentifiedStructTypes, Src,
|
|
|
|
DiagnosticHandler);
|
2014-10-25 12:06:10 +08:00
|
|
|
return TheLinker.run();
|
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.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// This function links two modules together, with the resulting Dest module
|
|
|
|
/// modified to be the composite of the two input modules. If an error occurs,
|
|
|
|
/// true is returned and ErrorMsg (if not null) is set to indicate the problem.
|
|
|
|
/// Upon failure, the Dest module could be in a modified state, and shouldn't be
|
|
|
|
/// relied on to be consistent.
|
2014-10-28 08:24:16 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src,
|
2014-10-28 07:02:10 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler) {
|
|
|
|
Linker L(Dest, DiagnosticHandler);
|
2014-10-28 08:24:16 +08:00
|
|
|
return L.linkInModule(Src);
|
2014-10-28 07:02:10 +08:00
|
|
|
}
|
|
|
|
|
2014-10-28 08:24:16 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src) {
|
2013-05-04 12:08:02 +08:00
|
|
|
Linker L(Dest);
|
2014-10-28 08:24:16 +08:00
|
|
|
return L.linkInModule(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
|
|
|
}
|
2012-05-09 16:55:40 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// C API.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
LLVMBool LLVMLinkModules(LLVMModuleRef Dest, LLVMModuleRef Src,
|
|
|
|
LLVMLinkerMode Mode, char **OutMessages) {
|
2014-10-25 12:31:08 +08:00
|
|
|
Module *D = unwrap(Dest);
|
|
|
|
std::string Message;
|
2014-10-28 07:02:10 +08:00
|
|
|
raw_string_ostream Stream(Message);
|
|
|
|
DiagnosticPrinterRawOStream DP(Stream);
|
|
|
|
|
|
|
|
LLVMBool Result = Linker::LinkModules(
|
2014-10-28 08:24:16 +08:00
|
|
|
D, unwrap(Src), [&](const DiagnosticInfo &DI) { DI.print(DP); });
|
2014-10-25 12:31:08 +08:00
|
|
|
|
|
|
|
if (OutMessages && Result)
|
|
|
|
*OutMessages = strdup(Message.c_str());
|
2012-05-09 16:55:40 +08:00
|
|
|
return Result;
|
|
|
|
}
|