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"
|
2014-12-04 06:36:37 +08:00
|
|
|
#include "llvm/ADT/Hashing.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"
|
2014-12-04 06:36:37 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2015-02-13 08:40:41 +08:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2014-12-18 09:05:33 +08:00
|
|
|
#include "llvm/IR/DebugInfo.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 {
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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-04 06:36:37 +08:00
|
|
|
TypeMapTy(Linker::IdentifiedStructTypeSet &DstStructTypesSet)
|
|
|
|
: DstStructTypesSet(DstStructTypesSet) {}
|
2013-05-04 13:05:18 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
Linker::IdentifiedStructTypeSet &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-12-04 06:36:37 +08:00
|
|
|
Type *get(Type *SrcTy, SmallPtrSet<StructType *, 8> &Visited);
|
|
|
|
|
|
|
|
void finishType(StructType *DTy, StructType *STy, ArrayRef<Type *> ETypes);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 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
|
|
|
}
|
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
void TypeMapTy::finishType(StructType *DTy, StructType *STy,
|
|
|
|
ArrayRef<Type *> ETypes) {
|
|
|
|
DTy->setBody(ETypes, STy->isPacked());
|
|
|
|
|
|
|
|
// Steal STy's name.
|
|
|
|
if (STy->hasName()) {
|
|
|
|
SmallString<16> TmpName = STy->getName();
|
|
|
|
STy->setName("");
|
|
|
|
DTy->setName(TmpName);
|
2014-12-02 00:32:20 +08:00
|
|
|
}
|
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
DstStructTypesSet.addNonOpaque(DTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
Type *TypeMapTy::get(Type *Ty) {
|
|
|
|
SmallPtrSet<StructType *, 8> Visited;
|
|
|
|
return get(Ty, Visited);
|
|
|
|
}
|
|
|
|
|
|
|
|
Type *TypeMapTy::get(Type *Ty, SmallPtrSet<StructType *, 8> &Visited) {
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
// These are types that LLVM itself will unique.
|
|
|
|
bool IsUniqued = !isa<StructType>(Ty) || cast<StructType>(Ty)->isLiteral();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
if (!IsUniqued) {
|
|
|
|
for (auto &Pair : MappedTypes) {
|
|
|
|
assert(!(Pair.first != Ty && Pair.second == Ty) &&
|
|
|
|
"mapping to a source type");
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
}
|
2014-12-04 06:36:37 +08:00
|
|
|
}
|
|
|
|
#endif
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
if (!IsUniqued && !Visited.insert(cast<StructType>(Ty)).second) {
|
|
|
|
StructType *DTy = StructType::create(Ty->getContext());
|
|
|
|
return *Entry = DTy;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
// If this is not a recursive type, then just map all of the elements and
|
|
|
|
// then rebuild the type from inside out.
|
|
|
|
SmallVector<Type *, 4> ElementTypes;
|
|
|
|
|
|
|
|
// 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 && IsUniqued)
|
|
|
|
return *Entry = Ty;
|
|
|
|
|
|
|
|
// Remap all of the elements, keeping track of whether any of them change.
|
|
|
|
bool AnyChange = false;
|
|
|
|
ElementTypes.resize(Ty->getNumContainedTypes());
|
|
|
|
for (unsigned I = 0, E = Ty->getNumContainedTypes(); I != E; ++I) {
|
|
|
|
ElementTypes[I] = get(Ty->getContainedType(I), Visited);
|
|
|
|
AnyChange |= ElementTypes[I] != Ty->getContainedType(I);
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
// If we found our type while recursively processing stuff, just use it.
|
|
|
|
Entry = &MappedTypes[Ty];
|
|
|
|
if (*Entry) {
|
|
|
|
if (auto *DTy = dyn_cast<StructType>(*Entry)) {
|
|
|
|
if (DTy->isOpaque()) {
|
|
|
|
auto *STy = cast<StructType>(Ty);
|
|
|
|
finishType(DTy, STy, ElementTypes);
|
|
|
|
}
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
2014-12-04 06:36:37 +08:00
|
|
|
return *Entry;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
// If all of the element types mapped directly over and the type is not
|
|
|
|
// a nomed struct, then the type is usable as-is.
|
|
|
|
if (!AnyChange && IsUniqued)
|
|
|
|
return *Entry = Ty;
|
|
|
|
|
|
|
|
// Otherwise, rebuild a modified type.
|
|
|
|
switch (Ty->getTypeID()) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unknown derived type to remap");
|
|
|
|
case Type::ArrayTyID:
|
|
|
|
return *Entry = ArrayType::get(ElementTypes[0],
|
|
|
|
cast<ArrayType>(Ty)->getNumElements());
|
|
|
|
case Type::VectorTyID:
|
|
|
|
return *Entry = VectorType::get(ElementTypes[0],
|
|
|
|
cast<VectorType>(Ty)->getNumElements());
|
|
|
|
case Type::PointerTyID:
|
|
|
|
return *Entry = PointerType::get(ElementTypes[0],
|
|
|
|
cast<PointerType>(Ty)->getAddressSpace());
|
|
|
|
case Type::FunctionTyID:
|
|
|
|
return *Entry = FunctionType::get(ElementTypes[0],
|
|
|
|
makeArrayRef(ElementTypes).slice(1),
|
|
|
|
cast<FunctionType>(Ty)->isVarArg());
|
|
|
|
case Type::StructTyID: {
|
|
|
|
auto *STy = cast<StructType>(Ty);
|
|
|
|
bool IsPacked = STy->isPacked();
|
|
|
|
if (IsUniqued)
|
|
|
|
return *Entry = StructType::get(Ty->getContext(), ElementTypes, IsPacked);
|
|
|
|
|
|
|
|
// If the type is opaque, we can just use it directly.
|
|
|
|
if (STy->isOpaque()) {
|
|
|
|
DstStructTypesSet.addOpaque(STy);
|
|
|
|
return *Entry = Ty;
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
if (StructType *OldT =
|
|
|
|
DstStructTypesSet.findNonOpaque(ElementTypes, IsPacked)) {
|
|
|
|
STy->setName("");
|
|
|
|
return *Entry = OldT;
|
|
|
|
}
|
2014-11-25 23:33:40 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
if (!AnyChange) {
|
|
|
|
DstStructTypesSet.addNonOpaque(STy);
|
|
|
|
return *Entry = Ty;
|
|
|
|
}
|
2014-11-25 23:33:40 +08:00
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
StructType *DTy = StructType::create(Ty->getContext());
|
|
|
|
finishType(DTy, STy, ElementTypes);
|
|
|
|
return *Entry = DTy;
|
|
|
|
}
|
2014-11-25 23:33:40 +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
|
|
|
}
|
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;
|
2014-12-09 02:45:16 +08:00
|
|
|
std::vector<GlobalValue *> &LazilyLinkGlobalValues;
|
2014-10-25 12:06:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
|
|
|
ValueMaterializerTy(TypeMapTy &TypeMap, Module *DstM,
|
2014-12-09 02:45:16 +08:00
|
|
|
std::vector<GlobalValue *> &LazilyLinkGlobalValues)
|
2014-11-25 14:11:24 +08:00
|
|
|
: ValueMaterializer(), TypeMap(TypeMap), DstM(DstM),
|
2014-12-09 02:45:16 +08:00
|
|
|
LazilyLinkGlobalValues(LazilyLinkGlobalValues) {}
|
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-12-09 02:45:16 +08:00
|
|
|
// Vector of GlobalValues to lazily link in.
|
|
|
|
std::vector<GlobalValue *> LazilyLinkGlobalValues;
|
2014-02-21 06:19:24 +08:00
|
|
|
|
2014-12-18 09:05:33 +08:00
|
|
|
/// Functions that have replaced other functions.
|
|
|
|
SmallPtrSet<const Function *, 16> OverridingFunctions;
|
|
|
|
|
2015-01-10 08:07:30 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler;
|
2014-10-28 07:02:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
2014-12-04 06:36:37 +08:00
|
|
|
ModuleLinker(Module *dstM, Linker::IdentifiedStructTypeSet &Set, Module *srcM,
|
2015-01-10 08:07:30 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler)
|
2014-12-02 00:32:20 +08:00
|
|
|
: DstM(dstM), SrcM(srcM), TypeMap(Set),
|
2014-12-09 02:45:16 +08:00
|
|
|
ValMaterializer(TypeMap, DstM, LazilyLinkGlobalValues),
|
2014-11-25 14:11:24 +08:00
|
|
|
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);
|
|
|
|
bool linkModuleFlagsMetadata();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void linkAppendingVarInit(const AppendingVarInfo &AVI);
|
2014-12-09 02:45:16 +08:00
|
|
|
|
|
|
|
void linkGlobalInit(GlobalVariable &Dst, GlobalVariable &Src);
|
|
|
|
bool linkFunctionBody(Function &Dst, Function &Src);
|
|
|
|
void linkAliasBody(GlobalAlias &Dst, GlobalAlias &Src);
|
|
|
|
bool linkGlobalValueBody(GlobalValue &Src);
|
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void linkNamedMDNodes();
|
2014-12-18 09:05:33 +08:00
|
|
|
void stripReplacedSubprograms();
|
2014-11-25 14:11:24 +08:00
|
|
|
};
|
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
|
|
|
DestGV->copyAttributesFrom(SrcGV);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
/// Loop through the global variables in the src module and merge them into the
|
|
|
|
/// dest module.
|
|
|
|
static GlobalVariable *copyGlobalVariableProto(TypeMapTy &TypeMap, Module &DstM,
|
|
|
|
const GlobalVariable *SGVar) {
|
|
|
|
// 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());
|
|
|
|
|
|
|
|
return NewDGV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Link the function in the source module into the destination module if
|
|
|
|
/// needed, setting up mapping information.
|
|
|
|
static Function *copyFunctionProto(TypeMapTy &TypeMap, Module &DstM,
|
|
|
|
const Function *SF) {
|
|
|
|
// If there is no linkage to be performed or we are linking from the source,
|
|
|
|
// bring SF over.
|
|
|
|
return Function::Create(TypeMap.get(SF->getFunctionType()), SF->getLinkage(),
|
|
|
|
SF->getName(), &DstM);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set up prototypes for any aliases that come over from the source module.
|
|
|
|
static GlobalAlias *copyGlobalAliasProto(TypeMapTy &TypeMap, Module &DstM,
|
|
|
|
const GlobalAlias *SGA) {
|
|
|
|
// If there is no linkage to be performed or we're linking from the source,
|
|
|
|
// bring over SGA.
|
|
|
|
auto *PTy = cast<PointerType>(TypeMap.get(SGA->getType()));
|
|
|
|
return GlobalAlias::create(PTy->getElementType(), PTy->getAddressSpace(),
|
|
|
|
SGA->getLinkage(), SGA->getName(), &DstM);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GlobalValue *copyGlobalValueProto(TypeMapTy &TypeMap, Module &DstM,
|
|
|
|
const GlobalValue *SGV) {
|
|
|
|
GlobalValue *NewGV;
|
|
|
|
if (auto *SGVar = dyn_cast<GlobalVariable>(SGV))
|
|
|
|
NewGV = copyGlobalVariableProto(TypeMap, DstM, SGVar);
|
|
|
|
else if (auto *SF = dyn_cast<Function>(SGV))
|
|
|
|
NewGV = copyFunctionProto(TypeMap, DstM, SF);
|
|
|
|
else
|
|
|
|
NewGV = copyGlobalAliasProto(TypeMap, DstM, cast<GlobalAlias>(SGV));
|
|
|
|
copyGVAttributes(NewGV, SGV);
|
|
|
|
return NewGV;
|
|
|
|
}
|
|
|
|
|
2013-05-28 23:17:05 +08:00
|
|
|
Value *ValueMaterializerTy::materializeValueFor(Value *V) {
|
2014-12-09 02:45:16 +08:00
|
|
|
auto *SGV = dyn_cast<GlobalValue>(V);
|
|
|
|
if (!SGV)
|
2014-04-15 14:32:26 +08:00
|
|
|
return nullptr;
|
2013-05-28 23:17:05 +08:00
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
GlobalValue *DGV = copyGlobalValueProto(TypeMap, *DstM, SGV);
|
2013-05-28 23:17:05 +08:00
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
if (Comdat *SC = SGV->getComdat()) {
|
|
|
|
if (auto *DGO = dyn_cast<GlobalObject>(DGV)) {
|
|
|
|
Comdat *DC = DstM->getOrInsertComdat(SC->getName());
|
|
|
|
DGO->setComdat(DC);
|
|
|
|
}
|
2014-08-16 04:17:08 +08:00
|
|
|
}
|
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
LazilyLinkGlobalValues.push_back(SGV);
|
|
|
|
return DGV;
|
2013-05-28 23:17:05 +08:00
|
|
|
}
|
|
|
|
|
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 }".
|
Ask the module for its the identified types.
When lazy reading a module, the types used in a function will not be visible to
a TypeFinder until the body is read.
This patch fixes that by asking the module for its identified struct types.
If a materializer is present, the module asks it. If not, it uses a TypeFinder.
This fixes pr21374.
I will be the first to say that this is ugly, but it was the best I could find.
Some of the options I looked at:
* Asking the LLVMContext. This could be made to work for gold, but not currently
for ld64. ld64 will load multiple modules into a single context before merging
them. This causes us to see types from future merges. Unfortunately,
MappedTypes is not just a cache when it comes to opaque types. Once the
mapping has been made, we have to remember it for as long as the key may
be used. This would mean moving MappedTypes to the Linker class and having
to drop the Linker::LinkModules static methods, which are visible from C.
* Adding an option to ignore function bodies in the TypeFinder. This would
fix the PR by picking the worst result. It would work, but unfortunately
we are currently quite dependent on the upfront type merging. I will
try to reduce our dependency, but it is not clear that we will be able
to get rid of it for now.
The only clean solution I could think of is making the Module own the types.
This would have other advantages, but it is a much bigger change. I will
propose it, but it is nice to have this fixed while that is discussed.
With the gold plugin, this patch takes the number of types in the LTO clang
binary from 52817 to 49669.
llvm-svn: 223215
2014-12-03 15:18:23 +08:00
|
|
|
std::vector<StructType *> Types = SrcM->getIdentifiedStructTypes();
|
|
|
|
for (StructType *ST : Types) {
|
2014-12-02 03:08:07 +08:00
|
|
|
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() == '.' ||
|
2014-12-02 03:17:46 +08:00
|
|
|
!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.
|
2014-12-02 03:17:46 +08:00
|
|
|
StructType *DST = DstM->getTypeByName(ST->getName().substr(0, DotPos));
|
|
|
|
if (!DST)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// 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-04 06:36:37 +08:00
|
|
|
if (TypeMap.DstStructTypesSet.hasType(DST))
|
2014-12-02 03:17:46 +08:00
|
|
|
TypeMap.addTypeMapping(DST, ST);
|
2012-02-28 07:48:30 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Now that we have discovered all of the type equivalences, get a body for
|
2014-05-09 22:39:25 +08:00
|
|
|
// any 'opaque' types in the dest module that are now resolved.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
TypeMap.linkDefinedTypeBodies();
|
2009-08-12 02:01:24 +08:00
|
|
|
}
|
|
|
|
|
2014-08-13 00:46:37 +08:00
|
|
|
static void upgradeGlobalArray(GlobalVariable *GV) {
|
|
|
|
ArrayType *ATy = cast<ArrayType>(GV->getType()->getElementType());
|
|
|
|
StructType *OldTy = cast<StructType>(ATy->getElementType());
|
|
|
|
assert(OldTy->getNumElements() == 2 && "Expected to upgrade from 2 elements");
|
|
|
|
|
|
|
|
// Get the upgraded 3 element type.
|
|
|
|
PointerType *VoidPtrTy = Type::getInt8Ty(GV->getContext())->getPointerTo();
|
|
|
|
Type *Tys[3] = {OldTy->getElementType(0), OldTy->getElementType(1),
|
|
|
|
VoidPtrTy};
|
|
|
|
StructType *NewTy = StructType::get(GV->getContext(), Tys, false);
|
|
|
|
|
|
|
|
// Build new constants with a null third field filled in.
|
|
|
|
Constant *OldInitC = GV->getInitializer();
|
|
|
|
ConstantArray *OldInit = dyn_cast<ConstantArray>(OldInitC);
|
|
|
|
if (!OldInit && !isa<ConstantAggregateZero>(OldInitC))
|
|
|
|
// Invalid initializer; give up.
|
|
|
|
return;
|
|
|
|
std::vector<Constant *> Initializers;
|
|
|
|
if (OldInit && OldInit->getNumOperands()) {
|
|
|
|
Value *Null = Constant::getNullValue(VoidPtrTy);
|
|
|
|
for (Use &U : OldInit->operands()) {
|
|
|
|
ConstantStruct *Init = cast<ConstantStruct>(U.get());
|
|
|
|
Initializers.push_back(ConstantStruct::get(
|
|
|
|
NewTy, Init->getOperand(0), Init->getOperand(1), Null, nullptr));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(Initializers.size() == ATy->getNumElements() &&
|
|
|
|
"Failed to copy all array elements");
|
|
|
|
|
|
|
|
// Replace the old GV with a new one.
|
|
|
|
ATy = ArrayType::get(NewTy, Initializers.size());
|
|
|
|
Constant *NewInit = ConstantArray::get(ATy, Initializers);
|
|
|
|
GlobalVariable *NewGV = new GlobalVariable(
|
|
|
|
*GV->getParent(), ATy, GV->isConstant(), GV->getLinkage(), NewInit, "",
|
|
|
|
GV, GV->getThreadLocalMode(), GV->getType()->getAddressSpace(),
|
|
|
|
GV->isExternallyInitialized());
|
|
|
|
NewGV->copyAttributesFrom(GV);
|
|
|
|
NewGV->takeName(GV);
|
|
|
|
assert(GV->use_empty() && "program cannot use initializer list");
|
|
|
|
GV->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
void ModuleLinker::upgradeMismatchedGlobalArray(StringRef Name) {
|
|
|
|
// Look for the global arrays.
|
|
|
|
auto *DstGV = dyn_cast_or_null<GlobalVariable>(DstM->getNamedValue(Name));
|
|
|
|
if (!DstGV)
|
|
|
|
return;
|
|
|
|
auto *SrcGV = dyn_cast_or_null<GlobalVariable>(SrcM->getNamedValue(Name));
|
|
|
|
if (!SrcGV)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Check if the types already match.
|
|
|
|
auto *DstTy = cast<ArrayType>(DstGV->getType()->getElementType());
|
|
|
|
auto *SrcTy =
|
|
|
|
cast<ArrayType>(TypeMap.get(SrcGV->getType()->getElementType()));
|
|
|
|
if (DstTy == SrcTy)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Grab the element types. We can only upgrade an array of a two-field
|
|
|
|
// struct. Only bother if the other one has three-fields.
|
|
|
|
auto *DstEltTy = cast<StructType>(DstTy->getElementType());
|
|
|
|
auto *SrcEltTy = cast<StructType>(SrcTy->getElementType());
|
|
|
|
if (DstEltTy->getNumElements() == 2 && SrcEltTy->getNumElements() == 3) {
|
|
|
|
upgradeGlobalArray(DstGV);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (DstEltTy->getNumElements() == 3 && SrcEltTy->getNumElements() == 2)
|
|
|
|
upgradeGlobalArray(SrcGV);
|
|
|
|
|
|
|
|
// We can't upgrade any other differences.
|
|
|
|
}
|
|
|
|
|
|
|
|
void ModuleLinker::upgradeMismatchedGlobals() {
|
|
|
|
upgradeMismatchedGlobalArray("llvm.global_ctors");
|
|
|
|
upgradeMismatchedGlobalArray("llvm.global_dtors");
|
|
|
|
}
|
|
|
|
|
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;
|
2014-12-06 01:53:15 +08:00
|
|
|
if (!LinkFromSrc) {
|
|
|
|
NewGV = DGV;
|
|
|
|
} else {
|
2014-12-09 02:45:16 +08:00
|
|
|
// If the GV is to be lazily linked, don't create it just yet.
|
|
|
|
// The ValueMaterializerTy will deal with creating it if it's used.
|
|
|
|
if (!DGV && (SGV->hasLocalLinkage() || SGV->hasLinkOnceLinkage() ||
|
|
|
|
SGV->hasAvailableExternallyLinkage())) {
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
|
|
|
return false;
|
|
|
|
}
|
2014-06-28 02:19:56 +08:00
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
NewGV = copyGlobalValueProto(TypeMap, *DstM, SGV);
|
2014-12-18 09:05:33 +08:00
|
|
|
|
|
|
|
if (DGV && isa<Function>(DGV))
|
|
|
|
if (auto *NewF = dyn_cast<Function>(NewGV))
|
|
|
|
OverridingFunctions.insert(NewF);
|
2014-12-09 02:45:16 +08:00
|
|
|
}
|
2014-11-01 07:10:07 +08:00
|
|
|
|
2014-12-05 23:42:30 +08:00
|
|
|
NewGV->setUnnamedAddr(HasUnnamedAddr);
|
|
|
|
NewGV->setVisibility(Visibility);
|
2014-12-05 08:09:02 +08:00
|
|
|
|
2014-12-05 23:42:30 +08:00
|
|
|
if (auto *NewGO = dyn_cast<GlobalObject>(NewGV)) {
|
|
|
|
if (C)
|
|
|
|
NewGO->setComdat(C);
|
2014-11-02 21:28:57 +08:00
|
|
|
|
2014-12-05 23:42:30 +08:00
|
|
|
if (DGV && DGV->hasCommonLinkage() && SGV->hasCommonLinkage())
|
|
|
|
NewGO->setAlignment(std::max(DGV->getAlignment(), SGV->getAlignment()));
|
|
|
|
}
|
|
|
|
|
2014-12-06 00:05:19 +08:00
|
|
|
if (auto *NewGVar = dyn_cast<GlobalVariable>(NewGV)) {
|
|
|
|
auto *DGVar = dyn_cast_or_null<GlobalVariable>(DGV);
|
|
|
|
auto *SGVar = dyn_cast<GlobalVariable>(SGV);
|
|
|
|
if (DGVar && SGVar && DGVar->isDeclaration() && SGVar->isDeclaration() &&
|
|
|
|
(!DGVar->isConstant() || !SGVar->isConstant()))
|
|
|
|
NewGVar->setConstant(false);
|
|
|
|
}
|
|
|
|
|
2014-12-05 23:42:30 +08:00
|
|
|
// Make sure to remember this mapping.
|
|
|
|
if (NewGV != DGV) {
|
|
|
|
if (DGV) {
|
|
|
|
DGV->replaceAllUsesWith(ConstantExpr::getBitCast(NewGV, DGV->getType()));
|
|
|
|
DGV->eraseFromParent();
|
2014-11-02 21:28:57 +08:00
|
|
|
}
|
2014-12-05 23:42:30 +08:00
|
|
|
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-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.
|
2014-12-09 02:45:16 +08:00
|
|
|
void ModuleLinker::linkGlobalInit(GlobalVariable &Dst, GlobalVariable &Src) {
|
|
|
|
// Figure out what the initializer looks like in the dest module.
|
|
|
|
Dst.setInitializer(MapValue(Src.getInitializer(), ValueMap, 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.
|
2014-12-09 02:45:16 +08:00
|
|
|
bool ModuleLinker::linkFunctionBody(Function &Dst, Function &Src) {
|
|
|
|
assert(Dst.isDeclaration() && !Src.isDeclaration());
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2014-12-08 21:29:33 +08:00
|
|
|
// Materialize if needed.
|
2014-12-08 22:25:26 +08:00
|
|
|
if (std::error_code EC = Src.materialize())
|
2014-12-08 21:29:33 +08:00
|
|
|
return emitError(EC.message());
|
|
|
|
|
2014-12-08 21:44:38 +08:00
|
|
|
// Link in the prefix data.
|
2014-12-08 22:25:26 +08:00
|
|
|
if (Src.hasPrefixData())
|
2014-12-09 02:45:16 +08:00
|
|
|
Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap, RF_None, &TypeMap,
|
|
|
|
&ValMaterializer));
|
2014-12-08 21:44:38 +08:00
|
|
|
|
|
|
|
// Link in the prologue data.
|
2014-12-08 22:25:26 +08:00
|
|
|
if (Src.hasPrologueData())
|
2014-12-09 02:45:16 +08:00
|
|
|
Dst.setPrologueData(MapValue(Src.getPrologueData(), ValueMap, RF_None,
|
2014-12-08 21:44:38 +08:00
|
|
|
&TypeMap, &ValMaterializer));
|
|
|
|
|
2004-11-17 01:12:38 +08:00
|
|
|
// Go through and convert function arguments over, remembering the mapping.
|
2014-12-09 02:45:16 +08:00
|
|
|
Function::arg_iterator DI = Dst.arg_begin();
|
2014-12-08 22:25:26 +08:00
|
|
|
for (Argument &Arg : Src.args()) {
|
2014-12-08 22:20:10 +08:00
|
|
|
DI->setName(Arg.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.
|
2014-12-08 22:20:10 +08:00
|
|
|
ValueMap[&Arg] = DI;
|
|
|
|
++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.
|
2014-12-09 02:45:16 +08:00
|
|
|
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.
|
2014-12-09 02:45:16 +08:00
|
|
|
for (BasicBlock &BB : Dst)
|
2014-12-08 22:20:10 +08:00
|
|
|
for (Instruction &I : BB)
|
|
|
|
RemapInstruction(&I, ValueMap, RF_IgnoreMissingEntries, &TypeMap,
|
2014-10-28 08:24:16 +08:00
|
|
|
&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.
|
2014-12-08 22:25:26 +08:00
|
|
|
for (Argument &Arg : Src.args())
|
2014-12-08 22:20:10 +08:00
|
|
|
ValueMap.erase(&Arg);
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-08 22:25:26 +08:00
|
|
|
Src.Dematerialize();
|
2014-12-08 21:29:33 +08:00
|
|
|
return false;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
void ModuleLinker::linkAliasBody(GlobalAlias &Dst, GlobalAlias &Src) {
|
|
|
|
Constant *Aliasee = Src.getAliasee();
|
|
|
|
Constant *Val =
|
|
|
|
MapValue(Aliasee, ValueMap, RF_None, &TypeMap, &ValMaterializer);
|
|
|
|
Dst.setAliasee(Val);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ModuleLinker::linkGlobalValueBody(GlobalValue &Src) {
|
|
|
|
Value *Dst = ValueMap[&Src];
|
|
|
|
assert(Dst);
|
|
|
|
if (auto *F = dyn_cast<Function>(&Src))
|
|
|
|
return linkFunctionBody(cast<Function>(*Dst), *F);
|
|
|
|
if (auto *GVar = dyn_cast<GlobalVariable>(&Src)) {
|
|
|
|
linkGlobalInit(cast<GlobalVariable>(*Dst), *GVar);
|
|
|
|
return false;
|
2011-10-11 08:24:54 +08:00
|
|
|
}
|
2014-12-09 02:45:16 +08:00
|
|
|
linkAliasBody(cast<GlobalAlias>(*Dst), cast<GlobalAlias>(Src));
|
|
|
|
return false;
|
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)
|
2014-12-19 14:06:18 +08:00
|
|
|
DestNMD->addOperand(MapMetadata(I->getOperand(i), ValueMap, RF_None,
|
|
|
|
&TypeMap, &ValMaterializer));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2014-12-18 09:05:33 +08:00
|
|
|
/// Drop DISubprograms that have been superseded.
|
|
|
|
///
|
|
|
|
/// FIXME: this creates an asymmetric result: we strip losing subprograms from
|
|
|
|
/// DstM, but leave losing subprograms in SrcM. Instead we should also strip
|
2014-12-19 14:06:18 +08:00
|
|
|
/// losers from SrcM, but this requires extra plumbing in MapMetadata.
|
2014-12-18 09:05:33 +08:00
|
|
|
void ModuleLinker::stripReplacedSubprograms() {
|
|
|
|
// Avoid quadratic runtime by returning early when there's nothing to do.
|
|
|
|
if (OverridingFunctions.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Move the functions now, so the set gets cleared even on early returns.
|
|
|
|
auto Functions = std::move(OverridingFunctions);
|
|
|
|
OverridingFunctions.clear();
|
|
|
|
|
|
|
|
// Drop subprograms whose functions have been overridden by the new compile
|
|
|
|
// unit.
|
|
|
|
NamedMDNode *CompileUnits = DstM->getNamedMetadata("llvm.dbg.cu");
|
|
|
|
if (!CompileUnits)
|
|
|
|
return;
|
|
|
|
for (unsigned I = 0, E = CompileUnits->getNumOperands(); I != E; ++I) {
|
|
|
|
DICompileUnit CU(CompileUnits->getOperand(I));
|
|
|
|
assert(CU && "Expected valid compile unit");
|
|
|
|
|
|
|
|
DITypedArray<DISubprogram> SPs(CU.getSubprograms());
|
|
|
|
assert(SPs && "Expected valid subprogram array");
|
|
|
|
|
|
|
|
SmallVector<Metadata *, 16> NewSPs;
|
|
|
|
NewSPs.reserve(SPs.getNumElements());
|
|
|
|
for (unsigned S = 0, SE = SPs.getNumElements(); S != SE; ++S) {
|
|
|
|
DISubprogram SP = SPs.getElement(S);
|
|
|
|
if (SP && SP.getFunction() && Functions.count(SP.getFunction()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
NewSPs.push_back(SP);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Redirect operand to the overriding subprogram.
|
|
|
|
if (NewSPs.size() != SPs.getNumElements())
|
|
|
|
CU.replaceSubprograms(DIArray(MDNode::get(DstM->getContext(), NewSPs)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
2015-01-08 05:32:27 +08:00
|
|
|
DenseMap<MDString *, std::pair<MDNode *, unsigned>> Flags;
|
2013-01-17 02:39:23 +08:00
|
|
|
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);
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
ConstantInt *Behavior = mdconst::extract<ConstantInt>(Op->getOperand(0));
|
2013-01-17 02:39:23 +08:00
|
|
|
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 {
|
2015-01-08 05:32:27 +08:00
|
|
|
Flags[ID] = std::make_pair(Op, I);
|
2013-01-17 02:39:23 +08:00
|
|
|
}
|
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);
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
ConstantInt *SrcBehavior =
|
|
|
|
mdconst::extract<ConstantInt>(SrcOp->getOperand(0));
|
2013-01-17 02:39:23 +08:00
|
|
|
MDString *ID = cast<MDString>(SrcOp->getOperand(1));
|
2015-01-08 05:32:27 +08:00
|
|
|
MDNode *DstOp;
|
|
|
|
unsigned DstIndex;
|
|
|
|
std::tie(DstOp, DstIndex) = Flags.lookup(ID);
|
2013-01-17 02:39:23 +08:00
|
|
|
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) {
|
2015-01-08 05:32:27 +08:00
|
|
|
Flags[ID] = std::make_pair(SrcOp, DstModFlags->getNumOperands());
|
2013-01-17 02:39:23 +08:00
|
|
|
DstModFlags->addOperand(SrcOp);
|
|
|
|
continue;
|
2012-02-11 19:38:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// Otherwise, perform a merge.
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
ConstantInt *DstBehavior =
|
|
|
|
mdconst::extract<ConstantInt>(DstOp->getOperand(0));
|
2013-01-17 02:39:23 +08:00
|
|
|
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.
|
2015-01-08 05:32:27 +08:00
|
|
|
DstModFlags->setOperand(DstIndex, SrcOp);
|
|
|
|
Flags[ID].first = SrcOp;
|
2013-01-17 02:39:23 +08:00
|
|
|
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
|
|
|
|
2015-01-08 05:32:27 +08:00
|
|
|
auto replaceDstValue = [&](MDNode *New) {
|
|
|
|
Metadata *FlagOps[] = {DstOp->getOperand(0), ID, New};
|
|
|
|
MDNode *Flag = MDNode::get(DstM->getContext(), FlagOps);
|
|
|
|
DstModFlags->setOperand(DstIndex, Flag);
|
|
|
|
Flags[ID].first = Flag;
|
|
|
|
};
|
|
|
|
|
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));
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallVector<Metadata *, 8> MDs;
|
|
|
|
MDs.reserve(DstValue->getNumOperands() + SrcValue->getNumOperands());
|
2015-02-17 23:29:18 +08:00
|
|
|
MDs.append(DstValue->op_begin(), DstValue->op_end());
|
|
|
|
MDs.append(SrcValue->op_begin(), SrcValue->op_end());
|
2015-01-08 05:32:27 +08:00
|
|
|
|
|
|
|
replaceDstValue(MDNode::get(DstM->getContext(), MDs));
|
2013-01-17 05:38:56 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Module::AppendUnique: {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallSetVector<Metadata *, 16> Elts;
|
2013-01-17 05:38:56 +08:00
|
|
|
MDNode *DstValue = cast<MDNode>(DstOp->getOperand(2));
|
|
|
|
MDNode *SrcValue = cast<MDNode>(SrcOp->getOperand(2));
|
2015-02-17 23:29:18 +08:00
|
|
|
Elts.insert(DstValue->op_begin(), DstValue->op_end());
|
|
|
|
Elts.insert(SrcValue->op_begin(), SrcValue->op_end());
|
2015-01-08 05:32:27 +08:00
|
|
|
|
|
|
|
replaceDstValue(MDNode::get(DstM->getContext(),
|
|
|
|
makeArrayRef(Elts.begin(), Elts.end())));
|
2013-01-17 05:38:56 +08:00
|
|
|
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));
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
Metadata *ReqValue = Requirement->getOperand(1);
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2015-01-08 05:32:27 +08:00
|
|
|
MDNode *Op = Flags[Flag].first;
|
2013-01-17 02:39:23 +08:00
|
|
|
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
|
|
|
|
2015-02-13 08:40:41 +08:00
|
|
|
// This function returns true if the triples match.
|
|
|
|
static bool triplesMatch(const Triple &T0, const Triple &T1) {
|
|
|
|
// If vendor is apple, ignore the version number.
|
|
|
|
if (T0.getVendor() == Triple::Apple)
|
|
|
|
return T0.getArch() == T1.getArch() &&
|
|
|
|
T0.getSubArch() == T1.getSubArch() &&
|
|
|
|
T0.getVendor() == T1.getVendor() &&
|
|
|
|
T0.getOS() == T1.getOS();
|
|
|
|
|
|
|
|
return T0 == T1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This function returns the merged triple.
|
|
|
|
static std::string mergeTriples(const Triple &SrcTriple, const Triple &DstTriple) {
|
|
|
|
// If vendor is apple, pick the triple with the larger version number.
|
|
|
|
if (SrcTriple.getVendor() == Triple::Apple)
|
|
|
|
if (DstTriple.isOSVersionLT(SrcTriple))
|
|
|
|
return SrcTriple.str();
|
|
|
|
|
|
|
|
return DstTriple.str();
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
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
|
|
|
}
|
2015-02-13 08:40:41 +08:00
|
|
|
|
|
|
|
// Copy the target triple from the source to dest if the dest's is empty.
|
|
|
|
if (DstM->getTargetTriple().empty() && !SrcM->getTargetTriple().empty())
|
|
|
|
DstM->setTargetTriple(SrcM->getTargetTriple());
|
|
|
|
|
|
|
|
Triple SrcTriple(SrcM->getTargetTriple()), DstTriple(DstM->getTargetTriple());
|
|
|
|
|
|
|
|
if (!SrcM->getTargetTriple().empty() && !triplesMatch(SrcTriple, DstTriple))
|
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");
|
2015-02-13 08:40:41 +08:00
|
|
|
|
|
|
|
DstM->setTargetTriple(mergeTriples(SrcTriple, DstTriple));
|
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
|
|
|
|
2014-12-09 02:05:48 +08:00
|
|
|
for (const auto &Entry : DstM->getComdatSymbolTable()) {
|
|
|
|
const Comdat &C = Entry.getValue();
|
|
|
|
if (C.getSelectionKind() == Comdat::Any)
|
|
|
|
continue;
|
|
|
|
const GlobalValue *GV = SrcM->getNamedValue(C.getName());
|
|
|
|
assert(GV);
|
|
|
|
MapValue(GV, ValueMap, RF_None, &TypeMap, &ValMaterializer);
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Link in the function bodies that are defined in the source module into
|
|
|
|
// DstM.
|
2014-12-08 21:35:09 +08:00
|
|
|
for (Function &SF : *SrcM) {
|
|
|
|
// Skip if no body (function is external).
|
|
|
|
if (SF.isDeclaration())
|
|
|
|
continue;
|
|
|
|
|
2011-10-15 06:17:46 +08:00
|
|
|
// Skip if not linking from source.
|
2014-12-08 21:35:09 +08:00
|
|
|
if (DoNotLinkFromSource.count(&SF))
|
|
|
|
continue;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
if (linkGlobalValueBody(SF))
|
2014-12-08 21:29:33 +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
|
|
|
}
|
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.
|
2014-12-09 02:45:16 +08:00
|
|
|
for (GlobalAlias &Src : SrcM->aliases()) {
|
|
|
|
if (DoNotLinkFromSource.count(&Src))
|
|
|
|
continue;
|
|
|
|
linkGlobalValueBody(Src);
|
|
|
|
}
|
2008-03-06 07:08:47 +08:00
|
|
|
|
2014-12-18 09:05:33 +08:00
|
|
|
// Strip replaced subprograms before linking together compile units.
|
|
|
|
stripReplacedSubprograms();
|
|
|
|
|
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.
|
2014-12-09 02:45:16 +08:00
|
|
|
for (GlobalVariable &Src : SrcM->globals()) {
|
|
|
|
// Only process initialized GV's or ones not already in dest.
|
|
|
|
if (!Src.hasInitializer() || DoNotLinkFromSource.count(&Src))
|
|
|
|
continue;
|
|
|
|
linkGlobalValueBody(Src);
|
|
|
|
}
|
2014-01-16 14:29:36 +08:00
|
|
|
|
2011-11-02 08:24:56 +08:00
|
|
|
// Process vector of lazily linked in functions.
|
2014-12-09 02:45:16 +08:00
|
|
|
while (!LazilyLinkGlobalValues.empty()) {
|
|
|
|
GlobalValue *SGV = LazilyLinkGlobalValues.back();
|
|
|
|
LazilyLinkGlobalValues.pop_back();
|
2012-03-23 15:22:49 +08:00
|
|
|
|
2014-12-17 06:29:43 +08:00
|
|
|
assert(!SGV->isDeclaration() && "users should not pass down decls");
|
2014-12-09 02:45:16 +08:00
|
|
|
if (linkGlobalValueBody(*SGV))
|
2014-12-08 21:29:33 +08:00
|
|
|
return true;
|
2014-12-06 05:04:36 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2004-11-13 04:37:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-12-04 06:36:37 +08:00
|
|
|
Linker::StructTypeKeyInfo::KeyTy::KeyTy(ArrayRef<Type *> E, bool P)
|
|
|
|
: ETypes(E), IsPacked(P) {}
|
|
|
|
|
|
|
|
Linker::StructTypeKeyInfo::KeyTy::KeyTy(const StructType *ST)
|
|
|
|
: ETypes(ST->elements()), IsPacked(ST->isPacked()) {}
|
|
|
|
|
|
|
|
bool Linker::StructTypeKeyInfo::KeyTy::operator==(const KeyTy &That) const {
|
|
|
|
if (IsPacked != That.IsPacked)
|
|
|
|
return false;
|
|
|
|
if (ETypes != That.ETypes)
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Linker::StructTypeKeyInfo::KeyTy::operator!=(const KeyTy &That) const {
|
|
|
|
return !this->operator==(That);
|
|
|
|
}
|
|
|
|
|
|
|
|
StructType *Linker::StructTypeKeyInfo::getEmptyKey() {
|
|
|
|
return DenseMapInfo<StructType *>::getEmptyKey();
|
|
|
|
}
|
|
|
|
|
|
|
|
StructType *Linker::StructTypeKeyInfo::getTombstoneKey() {
|
|
|
|
return DenseMapInfo<StructType *>::getTombstoneKey();
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned Linker::StructTypeKeyInfo::getHashValue(const KeyTy &Key) {
|
|
|
|
return hash_combine(hash_combine_range(Key.ETypes.begin(), Key.ETypes.end()),
|
|
|
|
Key.IsPacked);
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned Linker::StructTypeKeyInfo::getHashValue(const StructType *ST) {
|
|
|
|
return getHashValue(KeyTy(ST));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Linker::StructTypeKeyInfo::isEqual(const KeyTy &LHS,
|
|
|
|
const StructType *RHS) {
|
|
|
|
if (RHS == getEmptyKey() || RHS == getTombstoneKey())
|
|
|
|
return false;
|
|
|
|
return LHS == KeyTy(RHS);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Linker::StructTypeKeyInfo::isEqual(const StructType *LHS,
|
|
|
|
const StructType *RHS) {
|
|
|
|
if (RHS == getEmptyKey())
|
|
|
|
return LHS == getEmptyKey();
|
|
|
|
|
|
|
|
if (RHS == getTombstoneKey())
|
|
|
|
return LHS == getTombstoneKey();
|
|
|
|
|
|
|
|
return KeyTy(LHS) == KeyTy(RHS);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Linker::IdentifiedStructTypeSet::addNonOpaque(StructType *Ty) {
|
|
|
|
assert(!Ty->isOpaque());
|
2014-12-07 03:22:54 +08:00
|
|
|
NonOpaqueStructTypes.insert(Ty);
|
2014-12-04 06:36:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void Linker::IdentifiedStructTypeSet::addOpaque(StructType *Ty) {
|
|
|
|
assert(Ty->isOpaque());
|
|
|
|
OpaqueStructTypes.insert(Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
StructType *
|
|
|
|
Linker::IdentifiedStructTypeSet::findNonOpaque(ArrayRef<Type *> ETypes,
|
|
|
|
bool IsPacked) {
|
|
|
|
Linker::StructTypeKeyInfo::KeyTy Key(ETypes, IsPacked);
|
|
|
|
auto I = NonOpaqueStructTypes.find_as(Key);
|
|
|
|
if (I == NonOpaqueStructTypes.end())
|
|
|
|
return nullptr;
|
2014-12-07 03:22:54 +08:00
|
|
|
return *I;
|
2014-12-04 06:36:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Linker::IdentifiedStructTypeSet::hasType(StructType *Ty) {
|
|
|
|
if (Ty->isOpaque())
|
|
|
|
return OpaqueStructTypes.count(Ty);
|
|
|
|
auto I = NonOpaqueStructTypes.find(Ty);
|
|
|
|
if (I == NonOpaqueStructTypes.end())
|
|
|
|
return false;
|
2014-12-07 03:22:54 +08:00
|
|
|
return *I == Ty;
|
2014-12-04 06:36:37 +08:00
|
|
|
}
|
|
|
|
|
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);
|
2014-12-04 06:36:37 +08:00
|
|
|
for (StructType *Ty : StructTypes) {
|
|
|
|
if (Ty->isOpaque())
|
|
|
|
IdentifiedStructTypes.addOpaque(Ty);
|
|
|
|
else
|
|
|
|
IdentifiedStructTypes.addNonOpaque(Ty);
|
|
|
|
}
|
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);
|
2015-01-21 03:24:59 +08:00
|
|
|
bool RetCode = TheLinker.run();
|
|
|
|
Composite->dropTriviallyDeadConstantArrays();
|
|
|
|
return RetCode;
|
2013-05-04 11:48:37 +08:00
|
|
|
}
|
|
|
|
|
2015-02-24 08:45:56 +08:00
|
|
|
void Linker::setModule(Module *Dst) {
|
|
|
|
init(Dst, DiagnosticHandler);
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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,
|
2015-03-03 02:59:38 +08:00
|
|
|
LLVMLinkerMode Unused, 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;
|
|
|
|
}
|