llvm-6502/include/llvm/IR/GVMaterializer.h
Rafael Espindola eee41dbb65 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

62 lines
1.9 KiB
C++

//===- 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 <system_error>
#include <vector>
namespace llvm {
class Function;
class GlobalValue;
class Module;
class StructType;
class GVMaterializer {
protected:
GVMaterializer() {}
public:
virtual ~GVMaterializer();
/// True if GV has been materialized and can be dematerialized back to
/// whatever backing store this GVMaterializer uses.
virtual bool isDematerializable(const GlobalValue *GV) const = 0;
/// Make sure the given GlobalValue is fully read.
///
virtual std::error_code materialize(GlobalValue *GV) = 0;
/// 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.
///
virtual void Dematerialize(GlobalValue *) {}
/// Make sure the entire Module has been completely read.
///
virtual std::error_code MaterializeModule(Module *M) = 0;
virtual std::vector<StructType *> getIdentifiedStructTypes() const = 0;
};
} // End llvm namespace
#endif