llvm-project/llvm/lib/Bitcode/Reader/MetadataLoader.h

89 lines
2.6 KiB
C
Raw Normal View History

//===-- Bitcode/Reader/MetadataLoader.h - Load Metadatas -------*- C++ -*-====//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This class handles loading Metadatas.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_LIB_BITCODE_READER_METADATALOADER_H
#define LLVM_LIB_BITCODE_READER_METADATALOADER_H
#include "llvm/ADT/SmallVector.h"
#include "llvm/Support/Error.h"
#include <functional>
#include <memory>
namespace llvm {
class BitcodeReaderValueList;
class BitstreamCursor;
class DISubprogram;
class Error;
class Function;
class Instruction;
class Metadata;
class MDNode;
class Module;
class Type;
/// Helper class that handles loading Metadatas and keeping them available.
class MetadataLoader {
class MetadataLoaderImpl;
std::unique_ptr<MetadataLoaderImpl> Pimpl;
Error parseMetadata(bool ModuleLevel);
public:
~MetadataLoader();
MetadataLoader(BitstreamCursor &Stream, Module &TheModule,
BitcodeReaderValueList &ValueList, bool IsImporting,
std::function<Type *(unsigned)> getTypeByID);
MetadataLoader &operator=(MetadataLoader &&);
MetadataLoader(MetadataLoader &&);
// Parse a module metadata block
Error parseModuleMetadata() { return parseMetadata(true); }
// Parse a function metadata block
Error parseFunctionMetadata() { return parseMetadata(false); }
/// Set the mode to strip TBAA metadata on load.
void setStripTBAA(bool StripTBAA = true);
/// Return true if the Loader is stripping TBAA metadata.
bool isStrippingTBAA();
// Return true there are remaining unresolved forward references.
bool hasFwdRefs() const;
/// Return the given metadata, creating a replaceable forward reference if
/// necessary.
Metadata *getMetadataFwdRefOrLoad(unsigned Idx);
MDNode *getMDNodeFwdRefOrNull(unsigned Idx);
2018-08-06 13:03:21 +08:00
/// Return the DISubprogram metadata for a Function if any, null otherwise.
DISubprogram *lookupSubprogramForFunction(Function *F);
/// Parse a `METADATA_ATTACHMENT` block for a function.
Error parseMetadataAttachment(
Function &F, const SmallVectorImpl<Instruction *> &InstructionList);
/// Parse a `METADATA_KIND` block for the current module.
Error parseMetadataKinds();
unsigned size() const;
void shrinkTo(unsigned N);
PR32382: Fix emitting complex DWARF expressions. The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
2017-04-18 09:21:53 +08:00
/// Perform bitcode upgrades on llvm.dbg.* calls.
void upgradeDebugIntrinsics(Function &F);
};
}
#endif // LLVM_LIB_BITCODE_READER_METADATALOADER_H