2010-08-24 18:50:07 +00:00
|
|
|
//===- ValueMapper.h - Remapping for constants and metadata -----*- C++ -*-===//
|
2007-11-09 12:16:58 +00:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 19:59:42 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-11-09 12:16:58 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the MapValue interface which is used by various parts of
|
|
|
|
// the Transforms/Utils library to implement cloning and linking facilities.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2010-08-24 18:50:07 +00:00
|
|
|
#ifndef LLVM_TRANSFORMS_UTILS_VALUEMAPPER_H
|
|
|
|
#define LLVM_TRANSFORMS_UTILS_VALUEMAPPER_H
|
2007-11-09 12:16:58 +00:00
|
|
|
|
2014-03-04 11:26:31 +00:00
|
|
|
#include "llvm/IR/ValueMap.h"
|
2007-11-09 12:16:58 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
class Value;
|
|
|
|
class Instruction;
|
2012-03-28 08:38:27 +00:00
|
|
|
typedef ValueMap<const Value *, WeakVH> ValueToValueMapTy;
|
2007-11-09 12:16:58 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
/// ValueMapTypeRemapper - This is a class that can be implemented by clients
|
|
|
|
/// to remap types when cloning constants and instructions.
|
|
|
|
class ValueMapTypeRemapper {
|
2012-09-26 06:36:36 +00:00
|
|
|
virtual void anchor(); // Out of line method.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
public:
|
2011-07-10 08:38:12 +00:00
|
|
|
virtual ~ValueMapTypeRemapper() {}
|
2014-05-19 04:43:03 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
/// remapType - The client should implement this method if they want to
|
|
|
|
/// remap types while mapping values.
|
|
|
|
virtual Type *remapType(Type *SrcTy) = 0;
|
|
|
|
};
|
2013-05-28 15:17:05 +00:00
|
|
|
|
|
|
|
/// ValueMaterializer - This is a class that can be implemented by clients
|
|
|
|
/// to materialize Values on demand.
|
|
|
|
class ValueMaterializer {
|
|
|
|
virtual void anchor(); // Out of line method.
|
|
|
|
public:
|
|
|
|
virtual ~ValueMaterializer() {}
|
|
|
|
|
|
|
|
/// materializeValueFor - The client should implement this method if they
|
|
|
|
/// want to generate a mapped Value on demand. For example, if linking
|
|
|
|
/// lazily.
|
|
|
|
virtual Value *materializeValueFor(Value *V) = 0;
|
|
|
|
};
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2011-01-08 08:15:20 +00:00
|
|
|
/// RemapFlags - These are flags that the value mapping APIs allow.
|
|
|
|
enum RemapFlags {
|
|
|
|
RF_None = 0,
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2011-01-08 08:15:20 +00:00
|
|
|
/// RF_NoModuleLevelChanges - If this flag is set, the remapper knows that
|
|
|
|
/// only local values within a function (such as an instruction or argument)
|
|
|
|
/// are mapped, not global values like functions and global metadata.
|
|
|
|
RF_NoModuleLevelChanges = 1,
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2011-01-08 08:15:20 +00:00
|
|
|
/// RF_IgnoreMissingEntries - If this flag is set, the remapper ignores
|
|
|
|
/// entries that are not in the value map. If it is unset, it aborts if an
|
|
|
|
/// operand is asked to be remapped which doesn't exist in the mapping.
|
|
|
|
RF_IgnoreMissingEntries = 2
|
|
|
|
};
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2011-01-08 08:15:20 +00:00
|
|
|
static inline RemapFlags operator|(RemapFlags LHS, RemapFlags RHS) {
|
|
|
|
return RemapFlags(unsigned(LHS)|unsigned(RHS));
|
|
|
|
}
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2010-08-26 15:41:53 +00:00
|
|
|
Value *MapValue(const Value *V, ValueToValueMapTy &VM,
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
RemapFlags Flags = RF_None,
|
2014-04-15 06:32:26 +00:00
|
|
|
ValueMapTypeRemapper *TypeMapper = nullptr,
|
|
|
|
ValueMaterializer *Materializer = nullptr);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
|
2010-08-26 15:41:53 +00:00
|
|
|
void RemapInstruction(Instruction *I, ValueToValueMapTy &VM,
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
RemapFlags Flags = RF_None,
|
2014-04-15 06:32:26 +00:00
|
|
|
ValueMapTypeRemapper *TypeMapper = nullptr,
|
|
|
|
ValueMaterializer *Materializer = nullptr);
|
2014-05-19 04:43:03 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
/// MapValue - provide versions that preserve type safety for MDNode and
|
|
|
|
/// Constants.
|
|
|
|
inline MDNode *MapValue(const MDNode *V, ValueToValueMapTy &VM,
|
|
|
|
RemapFlags Flags = RF_None,
|
2014-04-15 06:32:26 +00:00
|
|
|
ValueMapTypeRemapper *TypeMapper = nullptr,
|
|
|
|
ValueMaterializer *Materializer = nullptr) {
|
2013-05-28 15:17:05 +00:00
|
|
|
return cast<MDNode>(MapValue((const Value*)V, VM, Flags, TypeMapper,
|
|
|
|
Materializer));
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
}
|
|
|
|
inline Constant *MapValue(const Constant *V, ValueToValueMapTy &VM,
|
|
|
|
RemapFlags Flags = RF_None,
|
2014-04-15 06:32:26 +00:00
|
|
|
ValueMapTypeRemapper *TypeMapper = nullptr,
|
|
|
|
ValueMaterializer *Materializer = nullptr) {
|
2013-05-28 15:17:05 +00:00
|
|
|
return cast<Constant>(MapValue((const Value*)V, VM, Flags, TypeMapper,
|
|
|
|
Materializer));
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
}
|
2014-05-19 04:43:03 +00:00
|
|
|
|
2007-11-09 12:16:58 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
|
|
|
#endif
|