1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 04:02:41 +01:00
llvm-mirror/include/llvm/IR/GVMaterializer.h

64 lines
1.9 KiB
C
Raw Normal View History

//===- GVMaterializer.h - Interface for GV materializers --------*- C++ -*-===//
//
// 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.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_IR_GVMATERIALIZER_H
#define LLVM_IR_GVMATERIALIZER_H
#include "llvm/ADT/DenseMap.h"
#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. llvm-svn: 223215
2014-12-03 08:18:23 +01:00
#include <vector>
namespace llvm {
class Function;
class GlobalValue;
class Metadata;
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. llvm-svn: 223215
2014-12-03 08:18:23 +01:00
class StructType;
class GVMaterializer {
protected:
GVMaterializer() {}
public:
virtual ~GVMaterializer();
/// Make sure the given GlobalValue is fully read.
///
virtual std::error_code materialize(GlobalValue *GV) = 0;
/// Make sure the entire Module has been completely read.
///
virtual std::error_code materializeModule() = 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. llvm-svn: 223215
2014-12-03 08:18:23 +01:00
virtual std::error_code materializeMetadata() = 0;
virtual void setStripDebugInfo() = 0;
/// Client should define this interface if the mapping between metadata
/// values and value ids needs to be preserved, e.g. across materializer
/// instantiations. If OnlyTempMD is true, only those that have remained
/// temporary metadata are recorded in the map.
virtual void
saveMetadataList(DenseMap<const Metadata *, unsigned> &MetadataToIDs,
bool OnlyTempMD) {}
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 08:18:23 +01:00
virtual std::vector<StructType *> getIdentifiedStructTypes() const = 0;
};
} // End llvm namespace
#endif