2014-03-06 03:50:29 +00:00
|
|
|
//===- GVMaterializer.h - Interface for GV materializers --------*- C++ -*-===//
|
2010-01-27 20:34:15 +00:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file provides an abstract interface for loading a module from some
|
|
|
|
// place. This interface allows incremental or random access loading of
|
|
|
|
// functions from the file. This is useful for applications like JIT compilers
|
|
|
|
// or interprocedural optimizers that do not need the entire program in memory
|
|
|
|
// at the same time.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-03-06 03:50:29 +00:00
|
|
|
#ifndef LLVM_IR_GVMATERIALIZER_H
|
|
|
|
#define LLVM_IR_GVMATERIALIZER_H
|
2010-01-27 20:34:15 +00:00
|
|
|
|
2014-06-12 17:38:55 +00:00
|
|
|
#include <system_error>
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
|
|
|
#include <vector>
|
2010-01-27 20:34:15 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
class Function;
|
|
|
|
class GlobalValue;
|
|
|
|
class Module;
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
|
|
|
class StructType;
|
2010-01-27 20:34:15 +00:00
|
|
|
|
|
|
|
class GVMaterializer {
|
|
|
|
protected:
|
|
|
|
GVMaterializer() {}
|
|
|
|
|
|
|
|
public:
|
|
|
|
virtual ~GVMaterializer();
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// True if GV has been materialized and can be dematerialized back to
|
|
|
|
/// whatever backing store this GVMaterializer uses.
|
2010-01-27 20:34:15 +00:00
|
|
|
virtual bool isDematerializable(const GlobalValue *GV) const = 0;
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Make sure the given GlobalValue is fully read.
|
2010-01-27 20:34:15 +00:00
|
|
|
///
|
2014-10-24 22:50:48 +00:00
|
|
|
virtual std::error_code materialize(GlobalValue *GV) = 0;
|
2010-01-27 20:34:15 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// If the given GlobalValue is read in, and if the GVMaterializer supports
|
|
|
|
/// it, release the memory for the GV, and set it up to be materialized
|
|
|
|
/// lazily. If the Materializer doesn't support this capability, this method
|
|
|
|
/// is a noop.
|
2010-01-27 20:34:15 +00:00
|
|
|
///
|
2015-05-15 18:20:14 +00:00
|
|
|
virtual void dematerialize(GlobalValue *) {}
|
2010-01-27 20:34:15 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Make sure the entire Module has been completely read.
|
2010-01-27 20:34:15 +00:00
|
|
|
///
|
2015-05-15 18:20:14 +00:00
|
|
|
virtual std::error_code materializeModule(Module *M) = 0;
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
|
|
|
|
2015-03-13 21:54:20 +00:00
|
|
|
virtual std::error_code materializeMetadata() = 0;
|
2015-03-30 21:36:43 +00:00
|
|
|
virtual void setStripDebugInfo() = 0;
|
2015-03-13 21:54:20 +00:00
|
|
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
|
|
|
virtual std::vector<StructType *> getIdentifiedStructTypes() const = 0;
|
2010-01-27 20:34:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
} // End llvm namespace
|
|
|
|
|
|
|
|
#endif
|