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);
|
|
|
|
};
|
2015-06-23 17:49: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
|
|
|
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());
|
2015-03-06 08:50:21 +08:00
|
|
|
DstStructTypesSet.switchToNonOpaque(DstSTy);
|
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.
|
2015-10-20 06:15:55 +08:00
|
|
|
class ValueMaterializerTy final : public ValueMaterializer {
|
2015-11-03 08:14:15 +08:00
|
|
|
ModuleLinker *ModLinker;
|
2014-10-25 12:06:10 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
public:
|
2015-11-28 04:28:19 +08:00
|
|
|
ValueMaterializerTy(ModuleLinker *ModLinker) : ModLinker(ModLinker) {}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2015-11-28 04:28:19 +08:00
|
|
|
Value *materializeDeclFor(Value *V) override;
|
|
|
|
void materializeInitFor(GlobalValue *New, GlobalValue *Old) override;
|
2014-11-25 14:11: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
|
|
|
|
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;
|
|
|
|
|
|
|
|
// Set of items not to link in from source.
|
2015-12-01 02:54:24 +08:00
|
|
|
SmallPtrSet<const GlobalValue *, 16> DoNotLinkFromSource;
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2015-01-10 08:07:30 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler;
|
2014-10-28 07:02:10 +08:00
|
|
|
|
2015-04-22 12:11:00 +08:00
|
|
|
/// For symbol clashes, prefer those from Src.
|
2015-09-02 01:55:55 +08:00
|
|
|
unsigned Flags;
|
2015-04-22 12:11:00 +08:00
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
/// Function index passed into ModuleLinker for using in function
|
|
|
|
/// importing/exporting handling.
|
2015-11-23 09:59:16 +08:00
|
|
|
const FunctionInfoIndex *ImportIndex;
|
2015-11-03 08:14:15 +08:00
|
|
|
|
|
|
|
/// Function to import from source module, all other functions are
|
|
|
|
/// imported as declarations instead of definitions.
|
|
|
|
Function *ImportFunction;
|
|
|
|
|
|
|
|
/// Set to true if the given FunctionInfoIndex contains any functions
|
|
|
|
/// from this source module, in which case we must conservatively assume
|
|
|
|
/// that any of its functions may be imported into another module
|
|
|
|
/// as part of a different backend compilation process.
|
|
|
|
bool HasExportedFunctions;
|
|
|
|
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
/// Set to true when all global value body linking is complete (including
|
|
|
|
/// lazy linking). Used to prevent metadata linking from creating new
|
|
|
|
/// references.
|
|
|
|
bool DoneLinkingBodies;
|
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
bool HasError = false;
|
|
|
|
|
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-11-03 08:14:15 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler, unsigned Flags,
|
2015-11-23 09:59:16 +08:00
|
|
|
const FunctionInfoIndex *Index = nullptr,
|
2015-11-03 08:14:15 +08:00
|
|
|
Function *FuncToImport = nullptr)
|
2015-11-28 04:28:19 +08:00
|
|
|
: DstM(dstM), SrcM(srcM), TypeMap(Set), ValMaterializer(this),
|
2015-11-03 08:14:15 +08:00
|
|
|
DiagnosticHandler(DiagnosticHandler), Flags(Flags), ImportIndex(Index),
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
ImportFunction(FuncToImport), HasExportedFunctions(false),
|
|
|
|
DoneLinkingBodies(false) {
|
2015-11-03 08:14:15 +08:00
|
|
|
assert((ImportIndex || !ImportFunction) &&
|
|
|
|
"Expect a FunctionInfoIndex when importing");
|
|
|
|
// If we have a FunctionInfoIndex but no function to import,
|
|
|
|
// then this is the primary module being compiled in a ThinLTO
|
|
|
|
// backend compilation, and we need to see if it has functions that
|
|
|
|
// may be exported to another backend compilation.
|
|
|
|
if (ImportIndex && !ImportFunction)
|
|
|
|
HasExportedFunctions = ImportIndex->hasExportedFunctions(SrcM);
|
|
|
|
}
|
2014-02-21 06:19:24 +08:00
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
bool run();
|
2015-11-28 04:28:19 +08:00
|
|
|
Value *materializeDeclFor(Value *V);
|
|
|
|
void materializeInitFor(GlobalValue *New, GlobalValue *Old);
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2015-11-28 04:28:19 +08:00
|
|
|
private:
|
2015-09-02 01:55:55 +08:00
|
|
|
bool shouldOverrideFromSrc() { return Flags & Linker::OverrideFromSrc; }
|
|
|
|
bool shouldLinkOnlyNeeded() { return Flags & Linker::LinkOnlyNeeded; }
|
|
|
|
bool shouldInternalizeLinkedSymbols() {
|
|
|
|
return Flags & Linker::InternalizeLinkedSymbols;
|
|
|
|
}
|
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
/// Handles cloning of a global values from the source module into
|
|
|
|
/// the destination module, including setting the attributes and visibility.
|
|
|
|
GlobalValue *copyGlobalValueProto(TypeMapTy &TypeMap, const GlobalValue *SGV,
|
|
|
|
const GlobalValue *DGV = nullptr);
|
|
|
|
|
|
|
|
/// Check if we should promote the given local value to global scope.
|
|
|
|
bool doPromoteLocalToGlobal(const GlobalValue *SGV);
|
|
|
|
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
/// Check if all global value body linking is complete.
|
|
|
|
bool doneLinkingBodies() { return DoneLinkingBodies; }
|
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
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));
|
2015-12-01 23:19:48 +08:00
|
|
|
HasError = true;
|
2014-11-25 14:11:24 +08:00
|
|
|
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);
|
2015-11-11 05:09:06 +08:00
|
|
|
// Keep track of the global value members of each comdat in source.
|
|
|
|
DenseMap<const Comdat *, std::vector<GlobalValue *>> ComdatMembers;
|
2014-11-25 14:11:24 +08:00
|
|
|
|
|
|
|
/// 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.
|
2015-11-25 03:46:58 +08:00
|
|
|
if (!SrcGV->hasName() || GlobalValue::isLocalLinkage(getLinkage(SrcGV)))
|
2014-11-25 14:11:24 +08:00
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Otherwise see if we have a match in the destination module's symtab.
|
2015-11-25 03:46:58 +08:00
|
|
|
GlobalValue *DGV = DstM->getNamedValue(getName(SrcGV));
|
2014-11-25 14:11:24 +08:00
|
|
|
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
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
bool linkIfNeeded(GlobalValue &GV);
|
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-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);
|
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
/// Functions that take care of cloning a specific global value type
|
|
|
|
/// into the destination module.
|
|
|
|
GlobalVariable *copyGlobalVariableProto(TypeMapTy &TypeMap,
|
|
|
|
const GlobalVariable *SGVar);
|
|
|
|
Function *copyFunctionProto(TypeMapTy &TypeMap, const Function *SF);
|
|
|
|
GlobalValue *copyGlobalAliasProto(TypeMapTy &TypeMap, const GlobalAlias *SGA);
|
|
|
|
|
|
|
|
/// Helper methods to check if we are importing from or potentially
|
|
|
|
/// exporting from the current source module.
|
|
|
|
bool isPerformingImport() { return ImportFunction != nullptr; }
|
|
|
|
bool isModuleExporting() { return HasExportedFunctions; }
|
|
|
|
|
|
|
|
/// If we are importing from the source module, checks if we should
|
|
|
|
/// import SGV as a definition, otherwise import as a declaration.
|
|
|
|
bool doImportAsDefinition(const GlobalValue *SGV);
|
|
|
|
|
|
|
|
/// Get the name for SGV that should be used in the linked destination
|
|
|
|
/// module. Specifically, this handles the case where we need to rename
|
|
|
|
/// a local that is being promoted to global scope.
|
|
|
|
std::string getName(const GlobalValue *SGV);
|
|
|
|
|
|
|
|
/// Get the new linkage for SGV that should be used in the linked destination
|
|
|
|
/// module. Specifically, for ThinLTO importing or exporting it may need
|
|
|
|
/// to be adjusted.
|
|
|
|
GlobalValue::LinkageTypes getLinkage(const GlobalValue *SGV);
|
|
|
|
|
|
|
|
/// Copies the necessary global value attributes and name from the source
|
|
|
|
/// to the newly cloned global value.
|
|
|
|
void copyGVAttributes(GlobalValue *NewGV, const GlobalValue *SrcGV);
|
|
|
|
|
|
|
|
/// Updates the visibility for the new global cloned from the source
|
|
|
|
/// and, if applicable, linked with an existing destination global.
|
|
|
|
/// Handles visibility change required for promoted locals.
|
|
|
|
void setVisibility(GlobalValue *NewGV, const GlobalValue *SGV,
|
|
|
|
const GlobalValue *DGV = nullptr);
|
|
|
|
|
2014-11-25 14:11:24 +08:00
|
|
|
void linkNamedMDNodes();
|
|
|
|
};
|
2015-06-23 17:49:53 +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.
|
2015-11-03 08:14:15 +08:00
|
|
|
// Note that any required local to global promotion should already be done,
|
|
|
|
// so promoted locals will not skip this handling as their linkage is no
|
|
|
|
// longer local.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 (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.
|
2015-11-03 08:14:15 +08:00
|
|
|
void ModuleLinker::copyGVAttributes(GlobalValue *NewGV,
|
|
|
|
const GlobalValue *SrcGV) {
|
|
|
|
auto *GA = dyn_cast<GlobalAlias>(SrcGV);
|
|
|
|
// Check for the special case of converting an alias (definition) to a
|
|
|
|
// non-alias (declaration). This can happen when we are importing and
|
|
|
|
// encounter a weak_any alias (weak_any defs may not be imported, see
|
|
|
|
// comments in ModuleLinker::getLinkage) or an alias whose base object is
|
|
|
|
// being imported as a declaration. In that case copy the attributes from the
|
|
|
|
// base object.
|
|
|
|
if (GA && !dyn_cast<GlobalAlias>(NewGV)) {
|
2015-11-11 02:20:11 +08:00
|
|
|
assert(isPerformingImport() && !doImportAsDefinition(GA));
|
2015-11-03 08:14:15 +08:00
|
|
|
NewGV->copyAttributesFrom(GA->getBaseObject());
|
|
|
|
} else
|
|
|
|
NewGV->copyAttributesFrom(SrcGV);
|
|
|
|
forceRenaming(NewGV, getName(SrcGV));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
bool ModuleLinker::doImportAsDefinition(const GlobalValue *SGV) {
|
|
|
|
if (!isPerformingImport())
|
|
|
|
return false;
|
2015-11-11 02:20:11 +08:00
|
|
|
auto *GA = dyn_cast<GlobalAlias>(SGV);
|
|
|
|
if (GA) {
|
|
|
|
if (GA->hasWeakAnyLinkage())
|
|
|
|
return false;
|
2015-11-27 03:22:59 +08:00
|
|
|
const GlobalObject *GO = GA->getBaseObject();
|
|
|
|
if (!GO->hasLinkOnceODRLinkage())
|
|
|
|
return false;
|
|
|
|
return doImportAsDefinition(GO);
|
2015-11-11 02:20:11 +08:00
|
|
|
}
|
2015-11-11 02:26:31 +08:00
|
|
|
// Always import GlobalVariable definitions, except for the special
|
|
|
|
// case of WeakAny which are imported as ExternalWeak declarations
|
|
|
|
// (see comments in ModuleLinker::getLinkage). The linkage changes
|
2015-11-03 08:14:15 +08:00
|
|
|
// described in ModuleLinker::getLinkage ensure the correct behavior (e.g.
|
|
|
|
// global variables with external linkage are transformed to
|
2015-11-11 02:20:11 +08:00
|
|
|
// available_externally definitions, which are ultimately turned into
|
|
|
|
// declarations after the EliminateAvailableExternally pass).
|
2015-11-18 15:07:59 +08:00
|
|
|
if (isa<GlobalVariable>(SGV) && !SGV->isDeclaration() &&
|
2015-11-11 02:20:11 +08:00
|
|
|
!SGV->hasWeakAnyLinkage())
|
2015-11-03 08:14:15 +08:00
|
|
|
return true;
|
|
|
|
// Only import the function requested for importing.
|
|
|
|
auto *SF = dyn_cast<Function>(SGV);
|
|
|
|
if (SF && SF == ImportFunction)
|
|
|
|
return true;
|
|
|
|
// Otherwise no.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ModuleLinker::doPromoteLocalToGlobal(const GlobalValue *SGV) {
|
|
|
|
assert(SGV->hasLocalLinkage());
|
|
|
|
// Both the imported references and the original local variable must
|
|
|
|
// be promoted.
|
|
|
|
if (!isPerformingImport() && !isModuleExporting())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Local const variables never need to be promoted unless they are address
|
|
|
|
// taken. The imported uses can simply use the clone created in this module.
|
|
|
|
// For now we are conservative in determining which variables are not
|
|
|
|
// address taken by checking the unnamed addr flag. To be more aggressive,
|
|
|
|
// the address taken information must be checked earlier during parsing
|
|
|
|
// of the module and recorded in the function index for use when importing
|
|
|
|
// from that module.
|
|
|
|
auto *GVar = dyn_cast<GlobalVariable>(SGV);
|
|
|
|
if (GVar && GVar->isConstant() && GVar->hasUnnamedAddr())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Eventually we only need to promote functions in the exporting module that
|
|
|
|
// are referenced by a potentially exported function (i.e. one that is in the
|
|
|
|
// function index).
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string ModuleLinker::getName(const GlobalValue *SGV) {
|
|
|
|
// For locals that must be promoted to global scope, ensure that
|
|
|
|
// the promoted name uniquely identifies the copy in the original module,
|
|
|
|
// using the ID assigned during combined index creation. When importing,
|
|
|
|
// we rename all locals (not just those that are promoted) in order to
|
|
|
|
// avoid naming conflicts between locals imported from different modules.
|
|
|
|
if (SGV->hasLocalLinkage() &&
|
|
|
|
(doPromoteLocalToGlobal(SGV) || isPerformingImport()))
|
|
|
|
return FunctionInfoIndex::getGlobalNameForLocal(
|
|
|
|
SGV->getName(),
|
|
|
|
ImportIndex->getModuleId(SGV->getParent()->getModuleIdentifier()));
|
|
|
|
return SGV->getName();
|
|
|
|
}
|
|
|
|
|
|
|
|
GlobalValue::LinkageTypes ModuleLinker::getLinkage(const GlobalValue *SGV) {
|
|
|
|
// Any local variable that is referenced by an exported function needs
|
|
|
|
// to be promoted to global scope. Since we don't currently know which
|
|
|
|
// functions reference which local variables/functions, we must treat
|
|
|
|
// all as potentially exported if this module is exporting anything.
|
|
|
|
if (isModuleExporting()) {
|
|
|
|
if (SGV->hasLocalLinkage() && doPromoteLocalToGlobal(SGV))
|
|
|
|
return GlobalValue::ExternalLinkage;
|
|
|
|
return SGV->getLinkage();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, if we aren't importing, no linkage change is needed.
|
|
|
|
if (!isPerformingImport())
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
switch (SGV->getLinkage()) {
|
|
|
|
case GlobalValue::ExternalLinkage:
|
|
|
|
// External defnitions are converted to available_externally
|
|
|
|
// definitions upon import, so that they are available for inlining
|
|
|
|
// and/or optimization, but are turned into declarations later
|
|
|
|
// during the EliminateAvailableExternally pass.
|
2015-11-11 02:20:11 +08:00
|
|
|
if (doImportAsDefinition(SGV) && !dyn_cast<GlobalAlias>(SGV))
|
2015-11-03 08:14:15 +08:00
|
|
|
return GlobalValue::AvailableExternallyLinkage;
|
|
|
|
// An imported external declaration stays external.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
case GlobalValue::AvailableExternallyLinkage:
|
|
|
|
// An imported available_externally definition converts
|
|
|
|
// to external if imported as a declaration.
|
|
|
|
if (!doImportAsDefinition(SGV))
|
|
|
|
return GlobalValue::ExternalLinkage;
|
|
|
|
// An imported available_externally declaration stays that way.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
case GlobalValue::LinkOnceAnyLinkage:
|
|
|
|
case GlobalValue::LinkOnceODRLinkage:
|
|
|
|
// These both stay the same when importing the definition.
|
|
|
|
// The ThinLTO pass will eventually force-import their definitions.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
case GlobalValue::WeakAnyLinkage:
|
|
|
|
// Can't import weak_any definitions correctly, or we might change the
|
|
|
|
// program semantics, since the linker will pick the first weak_any
|
|
|
|
// definition and importing would change the order they are seen by the
|
|
|
|
// linker. The module linking caller needs to enforce this.
|
|
|
|
assert(!doImportAsDefinition(SGV));
|
|
|
|
// If imported as a declaration, it becomes external_weak.
|
|
|
|
return GlobalValue::ExternalWeakLinkage;
|
|
|
|
|
|
|
|
case GlobalValue::WeakODRLinkage:
|
|
|
|
// For weak_odr linkage, there is a guarantee that all copies will be
|
|
|
|
// equivalent, so the issue described above for weak_any does not exist,
|
|
|
|
// and the definition can be imported. It can be treated similarly
|
|
|
|
// to an imported externally visible global value.
|
2015-11-11 02:20:11 +08:00
|
|
|
if (doImportAsDefinition(SGV) && !dyn_cast<GlobalAlias>(SGV))
|
2015-11-03 08:14:15 +08:00
|
|
|
return GlobalValue::AvailableExternallyLinkage;
|
|
|
|
else
|
|
|
|
return GlobalValue::ExternalLinkage;
|
|
|
|
|
|
|
|
case GlobalValue::AppendingLinkage:
|
|
|
|
// It would be incorrect to import an appending linkage variable,
|
|
|
|
// since it would cause global constructors/destructors to be
|
|
|
|
// executed multiple times. This should have already been handled
|
|
|
|
// by linkGlobalValueProto.
|
2015-11-13 10:16:51 +08:00
|
|
|
llvm_unreachable("Cannot import appending linkage variable");
|
2015-11-03 08:14:15 +08:00
|
|
|
|
|
|
|
case GlobalValue::InternalLinkage:
|
|
|
|
case GlobalValue::PrivateLinkage:
|
|
|
|
// If we are promoting the local to global scope, it is handled
|
|
|
|
// similarly to a normal externally visible global.
|
|
|
|
if (doPromoteLocalToGlobal(SGV)) {
|
2015-11-11 02:20:11 +08:00
|
|
|
if (doImportAsDefinition(SGV) && !dyn_cast<GlobalAlias>(SGV))
|
2015-11-03 08:14:15 +08:00
|
|
|
return GlobalValue::AvailableExternallyLinkage;
|
|
|
|
else
|
|
|
|
return GlobalValue::ExternalLinkage;
|
|
|
|
}
|
|
|
|
// A non-promoted imported local definition stays local.
|
|
|
|
// The ThinLTO pass will eventually force-import their definitions.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
case GlobalValue::ExternalWeakLinkage:
|
|
|
|
// External weak doesn't apply to definitions, must be a declaration.
|
|
|
|
assert(!doImportAsDefinition(SGV));
|
|
|
|
// Linkage stays external_weak.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
|
|
|
|
case GlobalValue::CommonLinkage:
|
|
|
|
// Linkage stays common on definitions.
|
|
|
|
// The ThinLTO pass will eventually force-import their definitions.
|
|
|
|
return SGV->getLinkage();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm_unreachable("unknown linkage type");
|
|
|
|
}
|
|
|
|
|
2014-12-09 02:45:16 +08:00
|
|
|
/// Loop through the global variables in the src module and merge them into the
|
|
|
|
/// dest module.
|
2015-11-03 08:14:15 +08:00
|
|
|
GlobalVariable *
|
|
|
|
ModuleLinker::copyGlobalVariableProto(TypeMapTy &TypeMap,
|
|
|
|
const GlobalVariable *SGVar) {
|
2014-12-09 02:45:16 +08:00
|
|
|
// No linking to be performed or linking from the source: simply create an
|
|
|
|
// identical version of the symbol over in the dest module... the
|
|
|
|
// initializer will be filled in later by LinkGlobalInits.
|
|
|
|
GlobalVariable *NewDGV = new GlobalVariable(
|
2015-11-03 08:14:15 +08:00
|
|
|
*DstM, TypeMap.get(SGVar->getType()->getElementType()),
|
|
|
|
SGVar->isConstant(), getLinkage(SGVar), /*init*/ nullptr, getName(SGVar),
|
|
|
|
/*insertbefore*/ nullptr, SGVar->getThreadLocalMode(),
|
2014-12-09 02:45:16 +08:00
|
|
|
SGVar->getType()->getAddressSpace());
|
|
|
|
|
|
|
|
return NewDGV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Link the function in the source module into the destination module if
|
|
|
|
/// needed, setting up mapping information.
|
2015-11-03 08:14:15 +08:00
|
|
|
Function *ModuleLinker::copyFunctionProto(TypeMapTy &TypeMap,
|
|
|
|
const Function *SF) {
|
2014-12-09 02:45:16 +08:00
|
|
|
// If there is no linkage to be performed or we are linking from the source,
|
|
|
|
// bring SF over.
|
2015-11-03 08:14:15 +08:00
|
|
|
return Function::Create(TypeMap.get(SF->getFunctionType()), getLinkage(SF),
|
|
|
|
getName(SF), DstM);
|
2014-12-09 02:45:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Set up prototypes for any aliases that come over from the source module.
|
2015-11-03 08:14:15 +08:00
|
|
|
GlobalValue *ModuleLinker::copyGlobalAliasProto(TypeMapTy &TypeMap,
|
|
|
|
const GlobalAlias *SGA) {
|
|
|
|
// If we are importing and encounter a weak_any alias, or an alias to
|
|
|
|
// an object being imported as a declaration, we must import the alias
|
|
|
|
// as a declaration as well, which involves converting it to a non-alias.
|
|
|
|
// See comments in ModuleLinker::getLinkage for why we cannot import
|
|
|
|
// weak_any defintions.
|
2015-11-11 02:20:11 +08:00
|
|
|
if (isPerformingImport() && !doImportAsDefinition(SGA)) {
|
2015-11-03 08:14:15 +08:00
|
|
|
// Need to convert to declaration. All aliases must be definitions.
|
|
|
|
const GlobalValue *GVal = SGA->getBaseObject();
|
|
|
|
GlobalValue *NewGV;
|
|
|
|
if (auto *GVar = dyn_cast<GlobalVariable>(GVal))
|
|
|
|
NewGV = copyGlobalVariableProto(TypeMap, GVar);
|
|
|
|
else {
|
|
|
|
auto *F = dyn_cast<Function>(GVal);
|
|
|
|
assert(F);
|
|
|
|
NewGV = copyFunctionProto(TypeMap, F);
|
|
|
|
}
|
2015-11-05 00:01:16 +08:00
|
|
|
// Set the linkage to External or ExternalWeak (see comments in
|
|
|
|
// ModuleLinker::getLinkage for why WeakAny is converted to ExternalWeak).
|
2015-11-03 08:14:15 +08:00
|
|
|
if (SGA->hasWeakAnyLinkage())
|
|
|
|
NewGV->setLinkage(GlobalValue::ExternalWeakLinkage);
|
2015-11-05 00:01:16 +08:00
|
|
|
else
|
|
|
|
NewGV->setLinkage(GlobalValue::ExternalLinkage);
|
2015-11-03 08:14:15 +08:00
|
|
|
return NewGV;
|
|
|
|
}
|
2014-12-09 02:45:16 +08:00
|
|
|
// If there is no linkage to be performed or we're linking from the source,
|
|
|
|
// bring over SGA.
|
2015-09-15 04:29:26 +08:00
|
|
|
auto *Ty = TypeMap.get(SGA->getValueType());
|
|
|
|
return GlobalAlias::create(Ty, SGA->getType()->getPointerAddressSpace(),
|
2015-11-03 08:14:15 +08:00
|
|
|
getLinkage(SGA), getName(SGA), DstM);
|
2014-12-09 02:45:16 +08:00
|
|
|
}
|
|
|
|
|
2015-11-29 22:33:06 +08:00
|
|
|
static GlobalValue::VisibilityTypes
|
|
|
|
getMinVisibility(GlobalValue::VisibilityTypes A,
|
|
|
|
GlobalValue::VisibilityTypes B) {
|
|
|
|
if (A == GlobalValue::HiddenVisibility || B == GlobalValue::HiddenVisibility)
|
|
|
|
return GlobalValue::HiddenVisibility;
|
|
|
|
if (A == GlobalValue::ProtectedVisibility ||
|
|
|
|
B == GlobalValue::ProtectedVisibility)
|
|
|
|
return GlobalValue::ProtectedVisibility;
|
|
|
|
return GlobalValue::DefaultVisibility;
|
|
|
|
}
|
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
void ModuleLinker::setVisibility(GlobalValue *NewGV, const GlobalValue *SGV,
|
|
|
|
const GlobalValue *DGV) {
|
|
|
|
GlobalValue::VisibilityTypes Visibility = SGV->getVisibility();
|
|
|
|
if (DGV)
|
2015-11-29 22:33:06 +08:00
|
|
|
Visibility = getMinVisibility(DGV->getVisibility(), Visibility);
|
2015-11-03 08:14:15 +08:00
|
|
|
// For promoted locals, mark them hidden so that they can later be
|
|
|
|
// stripped from the symbol table to reduce bloat.
|
|
|
|
if (SGV->hasLocalLinkage() && doPromoteLocalToGlobal(SGV))
|
|
|
|
Visibility = GlobalValue::HiddenVisibility;
|
|
|
|
NewGV->setVisibility(Visibility);
|
|
|
|
}
|
|
|
|
|
|
|
|
GlobalValue *ModuleLinker::copyGlobalValueProto(TypeMapTy &TypeMap,
|
|
|
|
const GlobalValue *SGV,
|
|
|
|
const GlobalValue *DGV) {
|
2014-12-09 02:45:16 +08:00
|
|
|
GlobalValue *NewGV;
|
|
|
|
if (auto *SGVar = dyn_cast<GlobalVariable>(SGV))
|
2015-11-03 08:14:15 +08:00
|
|
|
NewGV = copyGlobalVariableProto(TypeMap, SGVar);
|
2014-12-09 02:45:16 +08:00
|
|
|
else if (auto *SF = dyn_cast<Function>(SGV))
|
2015-11-03 08:14:15 +08:00
|
|
|
NewGV = copyFunctionProto(TypeMap, SF);
|
2014-12-09 02:45:16 +08:00
|
|
|
else
|
2015-11-03 08:14:15 +08:00
|
|
|
NewGV = copyGlobalAliasProto(TypeMap, cast<GlobalAlias>(SGV));
|
2014-12-09 02:45:16 +08:00
|
|
|
copyGVAttributes(NewGV, SGV);
|
2015-11-03 08:14:15 +08:00
|
|
|
setVisibility(NewGV, SGV, DGV);
|
2014-12-09 02:45:16 +08:00
|
|
|
return NewGV;
|
|
|
|
}
|
|
|
|
|
2015-11-28 04:28:19 +08:00
|
|
|
Value *ValueMaterializerTy::materializeDeclFor(Value *V) {
|
|
|
|
return ModLinker->materializeDeclFor(V);
|
|
|
|
}
|
|
|
|
|
|
|
|
Value *ModuleLinker::materializeDeclFor(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
|
|
|
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
// If we are done linking global value bodies (i.e. we are performing
|
|
|
|
// metadata linking), don't link in the global value due to this
|
|
|
|
// reference, simply map it to null.
|
2015-11-28 04:28:19 +08:00
|
|
|
if (doneLinkingBodies())
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
linkGlobalValueProto(SGV);
|
|
|
|
if (HasError)
|
|
|
|
return nullptr;
|
|
|
|
Value *Ret = ValueMap[SGV];
|
|
|
|
assert(Ret);
|
|
|
|
return Ret;
|
2013-05-28 23:17:05 +08:00
|
|
|
}
|
|
|
|
|
2015-11-28 04:28:19 +08:00
|
|
|
void ValueMaterializerTy::materializeInitFor(GlobalValue *New,
|
|
|
|
GlobalValue *Old) {
|
|
|
|
return ModLinker->materializeInitFor(New, Old);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ModuleLinker::materializeInitFor(GlobalValue *New, GlobalValue *Old) {
|
2015-12-01 23:19:48 +08:00
|
|
|
if (auto *F = dyn_cast<Function>(New)) {
|
|
|
|
if (!F->isDeclaration())
|
|
|
|
return;
|
|
|
|
} else if (auto *V = dyn_cast<GlobalVariable>(New)) {
|
|
|
|
if (V->hasInitializer())
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
auto *A = cast<GlobalAlias>(New);
|
|
|
|
if (A->getAliasee())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Old->isDeclaration())
|
|
|
|
return;
|
|
|
|
|
2015-11-28 04:28:19 +08:00
|
|
|
if (isPerformingImport() && !doImportAsDefinition(Old))
|
|
|
|
return;
|
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
if (!New->hasLocalLinkage() && DoNotLinkFromSource.count(Old))
|
2015-11-28 04:28:19 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
linkGlobalValueBody(*Old);
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
const DataLayout &DstDL = DstM->getDataLayout();
|
|
|
|
const DataLayout &SrcDL = SrcM->getDataLayout();
|
2014-06-28 02:19:56 +08:00
|
|
|
uint64_t DstSize =
|
2015-03-05 02:43:29 +08:00
|
|
|
DstDL.getTypeAllocSize(DstGV->getType()->getPointerElementType());
|
2014-06-28 02:19:56 +08:00
|
|
|
uint64_t SrcSize =
|
2015-03-05 02:43:29 +08:00
|
|
|
SrcDL.getTypeAllocSize(SrcGV->getType()->getPointerElementType());
|
2014-06-28 02:19:56 +08:00
|
|
|
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) {
|
2015-04-22 12:11:00 +08:00
|
|
|
// Should we unconditionally use the Src?
|
2015-09-02 01:55:55 +08:00
|
|
|
if (shouldOverrideFromSrc()) {
|
2015-04-22 12:11:00 +08:00
|
|
|
LinkFromSrc = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
// We always have to add Src if it has appending linkage.
|
|
|
|
if (Src.hasAppendingLinkage()) {
|
2015-11-03 08:14:15 +08:00
|
|
|
// Caller should have already determined that we can't link from source
|
|
|
|
// when importing (see comments in linkGlobalValueProto).
|
|
|
|
assert(!isPerformingImport());
|
2014-11-02 21:28:57 +08:00
|
|
|
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
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
if (isPerformingImport()) {
|
|
|
|
if (isa<Function>(&Src)) {
|
|
|
|
// For functions, LinkFromSrc iff this is the function requested
|
|
|
|
// for importing. For variables, decide below normally.
|
|
|
|
LinkFromSrc = (&Src == ImportFunction);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if this is an alias with an already existing definition
|
|
|
|
// in Dest, which must have come from a prior importing pass from
|
|
|
|
// the same Src module. Unlike imported function and variable
|
|
|
|
// definitions, which are imported as available_externally and are
|
|
|
|
// not definitions for the linker, that is not a valid linkage for
|
|
|
|
// imported aliases which must be definitions. Simply use the existing
|
|
|
|
// Dest copy.
|
|
|
|
if (isa<GlobalAlias>(&Src) && !DestIsDeclaration) {
|
|
|
|
assert(isa<GlobalAlias>(&Dest));
|
|
|
|
LinkFromSrc = false;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL = Dest.getParent()->getDataLayout();
|
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");
|
|
|
|
}
|
|
|
|
|
2015-12-02 01:17:04 +08:00
|
|
|
static void getArrayElements(const Constant *C,
|
|
|
|
SmallVectorImpl<Constant *> &Dest) {
|
|
|
|
unsigned NumElements = cast<ArrayType>(C->getType())->getNumElements();
|
|
|
|
|
|
|
|
for (unsigned i = 0; i != NumElements; ++i)
|
|
|
|
Dest.push_back(C->getAggregateElement(i));
|
|
|
|
}
|
|
|
|
|
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) {
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 *SrcTy =
|
2015-11-29 11:29:42 +08:00
|
|
|
cast<ArrayType>(TypeMap.get(SrcGV->getType()->getElementType()));
|
|
|
|
Type *EltTy = SrcTy->getElementType();
|
|
|
|
|
|
|
|
if (DstGV) {
|
|
|
|
ArrayType *DstTy = cast<ArrayType>(DstGV->getType()->getElementType());
|
|
|
|
|
|
|
|
if (!SrcGV->hasAppendingLinkage() || !DstGV->hasAppendingLinkage())
|
|
|
|
return emitError(
|
|
|
|
"Linking globals named '" + SrcGV->getName() +
|
|
|
|
"': can only link appending global with another appending global!");
|
|
|
|
|
|
|
|
// Check to see that they two arrays agree on type.
|
|
|
|
if (EltTy != DstTy->getElementType())
|
|
|
|
return emitError("Appending variables with different element types!");
|
|
|
|
if (DstGV->isConstant() != SrcGV->isConstant())
|
|
|
|
return emitError("Appending variables linked with different const'ness!");
|
|
|
|
|
|
|
|
if (DstGV->getAlignment() != SrcGV->getAlignment())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different alignment need to be linked!");
|
|
|
|
|
|
|
|
if (DstGV->getVisibility() != SrcGV->getVisibility())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different visibility need to be linked!");
|
|
|
|
|
|
|
|
if (DstGV->hasUnnamedAddr() != SrcGV->hasUnnamedAddr())
|
|
|
|
return emitError(
|
|
|
|
"Appending variables with different unnamed_addr need to be linked!");
|
|
|
|
|
|
|
|
if (StringRef(DstGV->getSection()) != SrcGV->getSection())
|
|
|
|
return emitError(
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
"Appending variables with different section name need to be linked!");
|
2015-11-29 11:29:42 +08:00
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2015-12-02 01:17:04 +08:00
|
|
|
SmallVector<Constant *, 16> DstElements;
|
|
|
|
if (DstGV)
|
|
|
|
getArrayElements(DstGV->getInitializer(), DstElements);
|
|
|
|
|
|
|
|
SmallVector<Constant *, 16> SrcElements;
|
|
|
|
getArrayElements(SrcGV->getInitializer(), SrcElements);
|
|
|
|
|
|
|
|
StringRef Name = SrcGV->getName();
|
|
|
|
bool IsNewStructor =
|
|
|
|
(Name == "llvm.global_ctors" || Name == "llvm.global_dtors") &&
|
|
|
|
cast<StructType>(EltTy)->getNumElements() == 3;
|
|
|
|
if (IsNewStructor)
|
|
|
|
SrcElements.erase(
|
|
|
|
std::remove_if(SrcElements.begin(), SrcElements.end(),
|
|
|
|
[this](Constant *E) {
|
|
|
|
auto *Key = dyn_cast<GlobalValue>(
|
|
|
|
E->getAggregateElement(2)->stripPointerCasts());
|
|
|
|
return DoNotLinkFromSource.count(Key);
|
|
|
|
}),
|
|
|
|
SrcElements.end());
|
|
|
|
uint64_t NewSize = DstElements.size() + SrcElements.size();
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 = 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.
|
2015-11-29 11:29:42 +08:00
|
|
|
GlobalVariable *NG = new GlobalVariable(
|
|
|
|
*DstM, NewType, SrcGV->isConstant(), SrcGV->getLinkage(),
|
|
|
|
/*init*/ nullptr, /*name*/ "", DstGV, SrcGV->getThreadLocalMode(),
|
|
|
|
SrcGV->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.
|
2015-11-29 11:29:42 +08:00
|
|
|
copyGVAttributes(NG, 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
|
|
|
// Replace any uses of the two global variables with uses of the new
|
|
|
|
// global.
|
|
|
|
ValueMap[SrcGV] = ConstantExpr::getBitCast(NG, TypeMap.get(SrcGV->getType()));
|
|
|
|
|
2015-12-02 01:17:04 +08:00
|
|
|
for (auto *V : SrcElements) {
|
|
|
|
DstElements.push_back(
|
|
|
|
MapValue(V, ValueMap, RF_MoveDistinctMDs, &TypeMap, &ValMaterializer));
|
|
|
|
}
|
|
|
|
|
|
|
|
NG->setInitializer(ConstantArray::get(NewType, DstElements));
|
|
|
|
|
2015-11-29 11:29:42 +08:00
|
|
|
if (DstGV) {
|
|
|
|
DstGV->replaceAllUsesWith(ConstantExpr::getBitCast(NG, DstGV->getType()));
|
|
|
|
DstGV->eraseFromParent();
|
|
|
|
}
|
2014-05-09 22:39:25 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
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.
|
2015-11-03 08:14:15 +08:00
|
|
|
assert(!DGV || SGV->hasAppendingLinkage() == DGV->hasAppendingLinkage());
|
|
|
|
if (SGV->hasAppendingLinkage() && isPerformingImport()) {
|
|
|
|
// Don't want to append to global_ctors list, for example, when we
|
|
|
|
// are importing for ThinLTO, otherwise the global ctors and dtors
|
|
|
|
// get executed multiple times for local variables (the latter causing
|
|
|
|
// double frees).
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
|
|
|
return false;
|
|
|
|
}
|
2015-11-29 11:29:42 +08:00
|
|
|
if (SGV->hasAppendingLinkage())
|
|
|
|
return linkAppendingVarProto(cast_or_null<GlobalVariable>(DGV),
|
2014-11-02 21:28:57 +08:00
|
|
|
cast<GlobalVariable>(SGV));
|
|
|
|
|
|
|
|
bool LinkFromSrc = true;
|
|
|
|
Comdat *C = nullptr;
|
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);
|
2015-12-01 23:19:48 +08:00
|
|
|
if (SGV->hasInternalLinkage())
|
|
|
|
LinkFromSrc = true;
|
2014-11-02 21:28:57 +08:00
|
|
|
} 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
|
|
|
|
2015-11-03 08:14:15 +08:00
|
|
|
if (DGV)
|
2014-11-02 21:28:57 +08:00
|
|
|
HasUnnamedAddr = HasUnnamedAddr && DGV->hasUnnamedAddr();
|
2014-05-09 22:39:25 +08:00
|
|
|
|
2014-11-02 21:28:57 +08:00
|
|
|
GlobalValue *NewGV;
|
2015-12-01 23:19:48 +08:00
|
|
|
if (!LinkFromSrc && DGV) {
|
2014-12-06 01:53:15 +08:00
|
|
|
NewGV = DGV;
|
2015-11-03 08:14:15 +08:00
|
|
|
// When linking from source we setVisibility from copyGlobalValueProto.
|
|
|
|
setVisibility(NewGV, SGV, DGV);
|
2014-12-06 01:53:15 +08:00
|
|
|
} else {
|
2015-11-03 08:14:15 +08:00
|
|
|
NewGV = copyGlobalValueProto(TypeMap, SGV, DGV);
|
2015-11-11 02:20:11 +08:00
|
|
|
|
|
|
|
if (isPerformingImport() && !doImportAsDefinition(SGV))
|
|
|
|
DoNotLinkFromSource.insert(SGV);
|
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);
|
2014-12-05 08:09:02 +08:00
|
|
|
|
2014-12-05 23:42:30 +08:00
|
|
|
if (auto *NewGO = dyn_cast<GlobalObject>(NewGV)) {
|
2015-12-01 23:19:48 +08:00
|
|
|
if (C && LinkFromSrc)
|
2014-12-05 23:42:30 +08:00
|
|
|
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-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.
|
2015-08-04 01:09:38 +08:00
|
|
|
Dst.setInitializer(MapValue(Src.getInitializer(), ValueMap,
|
|
|
|
RF_MoveDistinctMDs, &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())
|
2015-08-04 01:09:38 +08:00
|
|
|
Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap,
|
|
|
|
RF_MoveDistinctMDs, &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())
|
2015-08-04 01:09:38 +08:00
|
|
|
Dst.setPrologueData(MapValue(Src.getPrologueData(), ValueMap,
|
|
|
|
RF_MoveDistinctMDs, &TypeMap,
|
|
|
|
&ValMaterializer));
|
2014-12-08 21:44:38 +08:00
|
|
|
|
2015-06-18 04:52:32 +08:00
|
|
|
// Link in the personality function.
|
|
|
|
if (Src.hasPersonalityFn())
|
2015-08-04 01:09:38 +08:00
|
|
|
Dst.setPersonalityFn(MapValue(Src.getPersonalityFn(), ValueMap,
|
|
|
|
RF_MoveDistinctMDs, &TypeMap,
|
|
|
|
&ValMaterializer));
|
2015-06-18 04:52:32 +08:00
|
|
|
|
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.
|
2015-10-20 06:23:36 +08:00
|
|
|
ValueMap[&Arg] = &*DI;
|
2014-12-08 22:20:10 +08:00
|
|
|
++DI;
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
|
2015-04-25 06:07:31 +08:00
|
|
|
// Copy over the metadata attachments.
|
|
|
|
SmallVector<std::pair<unsigned, MDNode *>, 8> MDs;
|
|
|
|
Src.getAllMetadata(MDs);
|
|
|
|
for (const auto &I : MDs)
|
2015-08-04 01:09:38 +08:00
|
|
|
Dst.setMetadata(I.first, MapMetadata(I.second, ValueMap, RF_MoveDistinctMDs,
|
|
|
|
&TypeMap, &ValMaterializer));
|
2015-04-25 06:07:31 +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)
|
2015-08-04 01:09:38 +08:00
|
|
|
RemapInstruction(&I, ValueMap,
|
|
|
|
RF_IgnoreMissingEntries | RF_MoveDistinctMDs, &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
|
|
|
|
2015-05-16 02:20:14 +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();
|
2015-08-04 01:09:38 +08:00
|
|
|
Constant *Val = MapValue(Aliasee, ValueMap, RF_MoveDistinctMDs, &TypeMap,
|
|
|
|
&ValMaterializer);
|
2014-12-09 02:45:16 +08:00
|
|
|
Dst.setAliasee(Val);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ModuleLinker::linkGlobalValueBody(GlobalValue &Src) {
|
|
|
|
Value *Dst = ValueMap[&Src];
|
|
|
|
assert(Dst);
|
2015-11-11 05:09:06 +08:00
|
|
|
if (const Comdat *SC = Src.getComdat()) {
|
|
|
|
// To ensure that we don't generate an incomplete comdat group,
|
|
|
|
// we must materialize and map in any other members that are not
|
|
|
|
// yet materialized in Dst, which also ensures their definitions
|
|
|
|
// are linked in. Otherwise, linkonce and other lazy linked GVs will
|
|
|
|
// not be materialized if they aren't referenced.
|
|
|
|
for (auto *SGV : ComdatMembers[SC]) {
|
2015-11-28 04:28:19 +08:00
|
|
|
auto *DGV = cast_or_null<GlobalValue>(ValueMap[SGV]);
|
|
|
|
if (DGV && !DGV->isDeclaration())
|
2015-11-11 05:09:06 +08:00
|
|
|
continue;
|
2015-11-28 04:28:19 +08:00
|
|
|
MapValue(SGV, ValueMap, RF_MoveDistinctMDs, &TypeMap, &ValMaterializer);
|
2015-11-11 05:09:06 +08:00
|
|
|
}
|
|
|
|
}
|
2015-09-02 01:55:55 +08:00
|
|
|
if (shouldInternalizeLinkedSymbols())
|
|
|
|
if (auto *DGV = dyn_cast<GlobalValue>(Dst))
|
|
|
|
DGV->setLinkage(GlobalValue::InternalLinkage);
|
2014-12-09 02:45:16 +08:00
|
|
|
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();
|
2015-06-16 00:20:16 +08:00
|
|
|
for (const NamedMDNode &NMD : SrcM->named_metadata()) {
|
2012-02-11 19:38:06 +08:00
|
|
|
// Don't link module flags here. Do them separately.
|
2015-06-16 00:20:16 +08:00
|
|
|
if (&NMD == SrcModFlags)
|
|
|
|
continue;
|
|
|
|
NamedMDNode *DestNMD = DstM->getOrInsertNamedMetadata(NMD.getName());
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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 Src elements into Dest node.
|
2015-06-16 00:20:16 +08:00
|
|
|
for (const MDNode *op : NMD.operands())
|
2015-11-15 22:50:14 +08:00
|
|
|
DestNMD->addOperand(MapMetadata(
|
|
|
|
op, ValueMap, RF_MoveDistinctMDs | RF_NullMapMissingGlobalValues,
|
|
|
|
&TypeMap, &ValMaterializer));
|
2004-11-13 04:37:43 +08:00
|
|
|
}
|
|
|
|
}
|
2012-02-11 19:38:06 +08:00
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// Merge the linker flags in Src into the Dest module.
|
2012-02-11 19:38:06 +08:00
|
|
|
bool ModuleLinker::linkModuleFlagsMetadata() {
|
2013-01-17 02:39:23 +08:00
|
|
|
// If the source module has no module flags, we are done.
|
2012-02-11 19:38:06 +08:00
|
|
|
const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
|
|
|
|
if (!SrcModFlags) return false;
|
|
|
|
|
|
|
|
// If the destination module doesn't have module flags yet, then just copy
|
|
|
|
// over the source module's flags.
|
2013-01-17 02:39:23 +08:00
|
|
|
NamedMDNode *DstModFlags = DstM->getOrInsertModuleFlagsMetadata();
|
2012-02-11 19:38:06 +08:00
|
|
|
if (DstModFlags->getNumOperands() == 0) {
|
|
|
|
for (unsigned I = 0, E = SrcModFlags->getNumOperands(); I != E; ++I)
|
|
|
|
DstModFlags->addOperand(SrcModFlags->getOperand(I));
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-01-17 02:39:23 +08:00
|
|
|
// First build a map of the existing module flags and requirements.
|
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();
|
|
|
|
}
|
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
bool ModuleLinker::linkIfNeeded(GlobalValue &GV) {
|
|
|
|
GlobalValue *DGV = getLinkedToGlobal(&GV);
|
|
|
|
|
|
|
|
if (shouldLinkOnlyNeeded() && !(DGV && DGV->isDeclaration()))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (DGV && !GV.hasLocalLinkage()) {
|
|
|
|
GlobalValue::VisibilityTypes Visibility =
|
|
|
|
getMinVisibility(DGV->getVisibility(), GV.getVisibility());
|
|
|
|
DGV->setVisibility(Visibility);
|
|
|
|
GV.setVisibility(Visibility);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const Comdat *SC = GV.getComdat()) {
|
|
|
|
bool LinkFromSrc;
|
|
|
|
Comdat::SelectionKind SK;
|
|
|
|
std::tie(SK, LinkFromSrc) = ComdatsChosen[SC];
|
|
|
|
if (!LinkFromSrc) {
|
|
|
|
DoNotLinkFromSource.insert(&GV);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!DGV && !shouldOverrideFromSrc() &&
|
|
|
|
(GV.hasLocalLinkage() || GV.hasLinkOnceLinkage() ||
|
|
|
|
GV.hasAvailableExternallyLinkage())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
MapValue(&GV, ValueMap, RF_MoveDistinctMDs, &TypeMap, &ValMaterializer);
|
|
|
|
return HasError;
|
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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.
|
2015-03-05 02:43:29 +08:00
|
|
|
if (DstM->getDataLayout().isDefault())
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
if (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();
|
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
for (GlobalVariable &GV : SrcM->globals())
|
|
|
|
if (const Comdat *SC = GV.getComdat())
|
|
|
|
ComdatMembers[SC].push_back(&GV);
|
|
|
|
|
|
|
|
for (Function &SF : *SrcM)
|
|
|
|
if (const Comdat *SC = SF.getComdat())
|
|
|
|
ComdatMembers[SC].push_back(&SF);
|
|
|
|
|
|
|
|
for (GlobalAlias &GA : SrcM->aliases())
|
|
|
|
if (const Comdat *SC = GA.getComdat())
|
|
|
|
ComdatMembers[SC].push_back(&GA);
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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).
|
2015-06-16 00:20:16 +08:00
|
|
|
for (GlobalVariable &GV : SrcM->globals())
|
2015-12-01 23:19:48 +08:00
|
|
|
if (linkIfNeeded(GV))
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
2015-12-01 23:19:48 +08:00
|
|
|
for (Function &SF : *SrcM)
|
|
|
|
if (linkIfNeeded(SF))
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
return true;
|
2004-11-13 04:37:43 +08:00
|
|
|
|
2015-06-16 00:20:16 +08:00
|
|
|
for (GlobalAlias &GA : SrcM->aliases())
|
2015-12-01 23:19:48 +08:00
|
|
|
if (linkIfNeeded(GA))
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
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());
|
2015-06-23 05:46:51 +08:00
|
|
|
if (GV)
|
2015-08-04 01:09:38 +08:00
|
|
|
MapValue(GV, ValueMap, RF_MoveDistinctMDs, &TypeMap, &ValMaterializer);
|
2014-12-09 02:05:48 +08:00
|
|
|
}
|
|
|
|
|
Restore "Move metadata linking after lazy global materialization/linking."
Summary:
This reverts commit r251965.
Restore "Move metadata linking after lazy global materialization/linking."
This restores commit r251926, with fixes for the LTO bootstrapping bot
failure.
The bot failure was caused by references from debug metadata to
otherwise unreferenced globals. Previously, this caused the lazy linking
to link in their defs, which is unnecessary. With this patch, because
lazy linking is complete when we encounter the metadata reference, the
materializer created a declaration. For definitions such as aliases and
comdats, it is illegal to have a declaration. Furthermore, metadata
linking should not change code generation. Therefore, when linking of
global value bodies is complete, the materializer will simply return
nullptr as the new reference for the linked metadata.
This change required fixing a different test to ensure there was a
real reference to a linkonce global that was only being reference from
metadata.
Note that the new changes to the only-needed-named-metadata.ll test
illustrate an issue with llvm-link -only-needed handling of comdat
groups, whereby it may result in an incomplete comdat group. I note this
in the test comments, but the issue is orthogonal to this patch (it can
be reproduced without any metadata at head).
Reviewers: dexonsmith, rafael, tra
Subscribers: tobiasvk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D14447
llvm-svn: 252320
2015-11-07 01:50:53 +08:00
|
|
|
// Note that we are done linking global value bodies. This prevents
|
|
|
|
// metadata linking from creating new references.
|
|
|
|
DoneLinkingBodies = true;
|
|
|
|
|
2015-11-07 01:50:48 +08:00
|
|
|
// Remap all of the named MDNodes in Src into the DstM module. We do this
|
|
|
|
// after linking GlobalValues so that MDNodes that reference GlobalValues
|
|
|
|
// are properly remapped.
|
|
|
|
linkNamedMDNodes();
|
|
|
|
|
|
|
|
// Merge the module flags into the DstM module.
|
|
|
|
if (linkModuleFlagsMetadata())
|
|
|
|
return true;
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-03-06 08:50:21 +08:00
|
|
|
void Linker::IdentifiedStructTypeSet::switchToNonOpaque(StructType *Ty) {
|
|
|
|
assert(!Ty->isOpaque());
|
|
|
|
NonOpaqueStructTypes.insert(Ty);
|
|
|
|
bool Removed = OpaqueStructTypes.erase(Ty);
|
|
|
|
(void)Removed;
|
|
|
|
assert(Removed);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-12-02 02:46:19 +08:00
|
|
|
Linker::Linker(Module *M, DiagnosticHandlerFunction DiagnosticHandler) {
|
2014-11-18 04:51:01 +08:00
|
|
|
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
|
|
|
|
2015-12-02 02:46:19 +08:00
|
|
|
Linker::Linker(Module *M)
|
|
|
|
: Linker(M, [this](const DiagnosticInfo &DI) {
|
|
|
|
Composite->getContext().diagnose(DI);
|
|
|
|
}) {}
|
2014-11-18 04:51:01 +08:00
|
|
|
|
2015-11-23 09:59:16 +08:00
|
|
|
bool Linker::linkInModule(Module *Src, unsigned Flags,
|
|
|
|
const FunctionInfoIndex *Index,
|
2015-11-03 08:14:15 +08:00
|
|
|
Function *FuncToImport) {
|
2014-12-02 00:32:20 +08:00
|
|
|
ModuleLinker TheLinker(Composite, IdentifiedStructTypes, Src,
|
2015-11-03 08:14:15 +08:00
|
|
|
DiagnosticHandler, Flags, Index, FuncToImport);
|
2015-01-21 03:24:59 +08:00
|
|
|
bool RetCode = TheLinker.run();
|
|
|
|
Composite->dropTriviallyDeadConstantArrays();
|
|
|
|
return RetCode;
|
2013-05-04 11:48:37 +08:00
|
|
|
}
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// LinkModules entrypoint.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-10-27 10:35:46 +08:00
|
|
|
/// This function links two modules together, with the resulting Dest module
|
|
|
|
/// modified to be the composite of the two input modules. If an error occurs,
|
|
|
|
/// true is returned and ErrorMsg (if not null) is set to indicate the problem.
|
|
|
|
/// Upon failure, the Dest module could be in a modified state, and shouldn't be
|
|
|
|
/// relied on to be consistent.
|
2014-10-28 08:24:16 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src,
|
2015-09-02 01:55:55 +08:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler,
|
|
|
|
unsigned Flags) {
|
2014-10-28 07:02:10 +08:00
|
|
|
Linker L(Dest, DiagnosticHandler);
|
2015-09-02 01:55:55 +08:00
|
|
|
return L.linkInModule(Src, Flags);
|
2014-10-28 07:02:10 +08:00
|
|
|
}
|
|
|
|
|
2015-09-02 01:55:55 +08:00
|
|
|
bool Linker::LinkModules(Module *Dest, Module *Src, unsigned Flags) {
|
2013-05-04 12:08:02 +08:00
|
|
|
Linker L(Dest);
|
2015-09-02 01:55:55 +08:00
|
|
|
return L.linkInModule(Src, Flags);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are 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
|
|
|
|
2015-06-13 07:26:42 +08:00
|
|
|
if (OutMessages && Result) {
|
|
|
|
Stream.flush();
|
2014-10-25 12:31:08 +08:00
|
|
|
*OutMessages = strdup(Message.c_str());
|
2015-06-13 07:26:42 +08:00
|
|
|
}
|
2012-05-09 16:55:40 +08:00
|
|
|
return Result;
|
|
|
|
}
|