2007-04-22 06:23:29 +00:00
|
|
|
//===- BitcodeReader.h - Internal BitcodeReader impl ------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 20:36:04 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-04-22 06:23:29 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This header defines the BitcodeReader class.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-13 16:26:38 +00:00
|
|
|
#ifndef LLVM_LIB_BITCODE_READER_BITCODEREADER_H
|
|
|
|
#define LLVM_LIB_BITCODE_READER_BITCODEREADER_H
|
2007-04-22 06:23:29 +00:00
|
|
|
|
2012-12-04 07:12:27 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2007-05-01 04:59:48 +00:00
|
|
|
#include "llvm/Bitcode/BitstreamReader.h"
|
2007-04-23 01:01:37 +00:00
|
|
|
#include "llvm/Bitcode/LLVMBitCodes.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Attributes.h"
|
2014-03-06 03:50:29 +00:00
|
|
|
#include "llvm/IR/GVMaterializer.h"
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
#include "llvm/IR/Metadata.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/OperandTraits.h"
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
#include "llvm/IR/TrackingMDRef.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Type.h"
|
2014-03-04 11:17:44 +00:00
|
|
|
#include "llvm/IR/ValueHandle.h"
|
2014-08-05 17:49:48 +00:00
|
|
|
#include <deque>
|
2014-06-12 17:38:55 +00:00
|
|
|
#include <system_error>
|
2007-04-22 06:23:29 +00:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace llvm {
|
2014-06-27 18:19:56 +00:00
|
|
|
class Comdat;
|
2007-04-29 07:54:31 +00:00
|
|
|
class MemoryBuffer;
|
2009-08-11 17:45:13 +00:00
|
|
|
class LLVMContext;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2008-05-10 08:32:32 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// BitcodeReaderValueList Class
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-09-11 18:05:11 +00:00
|
|
|
class BitcodeReaderValueList {
|
2009-03-31 22:55:09 +00:00
|
|
|
std::vector<WeakVH> ValuePtrs;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2008-08-21 02:34:16 +00:00
|
|
|
/// ResolveConstants - As we resolve forward-referenced constants, we add
|
|
|
|
/// information about them to this vector. This allows us to resolve them in
|
|
|
|
/// bulk instead of resolving each reference at a time. See the code in
|
|
|
|
/// ResolveConstantForwardRefs for more information about this.
|
|
|
|
///
|
|
|
|
/// The key of this vector is the placeholder constant, the value is the slot
|
|
|
|
/// number that holds the resolved value.
|
|
|
|
typedef std::vector<std::pair<Constant*, unsigned> > ResolveConstantsTy;
|
|
|
|
ResolveConstantsTy ResolveConstants;
|
2011-07-07 05:12:37 +00:00
|
|
|
LLVMContext &Context;
|
2007-04-24 05:48:56 +00:00
|
|
|
public:
|
2011-07-07 05:12:37 +00:00
|
|
|
BitcodeReaderValueList(LLVMContext &C) : Context(C) {}
|
2008-08-21 02:34:16 +00:00
|
|
|
~BitcodeReaderValueList() {
|
|
|
|
assert(ResolveConstants.empty() && "Constants not resolved?");
|
|
|
|
}
|
2008-05-10 08:32:32 +00:00
|
|
|
|
2007-04-24 05:48:56 +00:00
|
|
|
// vector compatibility methods
|
2009-03-31 22:55:09 +00:00
|
|
|
unsigned size() const { return ValuePtrs.size(); }
|
|
|
|
void resize(unsigned N) { ValuePtrs.resize(N); }
|
2007-04-24 05:48:56 +00:00
|
|
|
void push_back(Value *V) {
|
2009-03-31 22:55:09 +00:00
|
|
|
ValuePtrs.push_back(V);
|
2007-04-24 05:48:56 +00:00
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2007-05-18 04:02:46 +00:00
|
|
|
void clear() {
|
2008-08-21 02:34:16 +00:00
|
|
|
assert(ResolveConstants.empty() && "Constants not resolved?");
|
2009-03-31 22:55:09 +00:00
|
|
|
ValuePtrs.clear();
|
2007-05-18 04:02:46 +00:00
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2009-03-31 22:55:09 +00:00
|
|
|
Value *operator[](unsigned i) const {
|
|
|
|
assert(i < ValuePtrs.size());
|
|
|
|
return ValuePtrs[i];
|
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2009-03-31 22:55:09 +00:00
|
|
|
Value *back() const { return ValuePtrs.back(); }
|
|
|
|
void pop_back() { ValuePtrs.pop_back(); }
|
|
|
|
bool empty() const { return ValuePtrs.empty(); }
|
2007-04-26 03:27:58 +00:00
|
|
|
void shrinkTo(unsigned N) {
|
2009-03-31 22:55:09 +00:00
|
|
|
assert(N <= size() && "Invalid shrinkTo request!");
|
|
|
|
ValuePtrs.resize(N);
|
2007-04-26 03:27:58 +00:00
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2011-07-18 04:54:35 +00:00
|
|
|
Constant *getConstantFwdRef(unsigned Idx, Type *Ty);
|
|
|
|
Value *getValueFwdRef(unsigned Idx, Type *Ty);
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2009-03-31 22:55:09 +00:00
|
|
|
void AssignValue(Value *V, unsigned Idx);
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2008-08-21 02:34:16 +00:00
|
|
|
/// ResolveConstantForwardRefs - Once all constants are read, this method bulk
|
|
|
|
/// resolves any forward references.
|
|
|
|
void ResolveConstantForwardRefs();
|
2008-05-10 08:32:32 +00:00
|
|
|
};
|
|
|
|
|
2009-08-04 06:00:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// BitcodeReaderMDValueList Class
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-09-11 18:05:11 +00:00
|
|
|
class BitcodeReaderMDValueList {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
unsigned NumFwdRefs;
|
|
|
|
bool AnyFwdRefs;
|
2015-02-16 19:18:01 +00:00
|
|
|
unsigned MinFwdRef;
|
|
|
|
unsigned MaxFwdRef;
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
std::vector<TrackingMDRef> MDValuePtrs;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2009-10-28 05:53:48 +00:00
|
|
|
LLVMContext &Context;
|
2009-08-04 06:00:18 +00:00
|
|
|
public:
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
BitcodeReaderMDValueList(LLVMContext &C)
|
|
|
|
: NumFwdRefs(0), AnyFwdRefs(false), Context(C) {}
|
2009-08-04 06:00:18 +00:00
|
|
|
|
|
|
|
// vector compatibility methods
|
|
|
|
unsigned size() const { return MDValuePtrs.size(); }
|
|
|
|
void resize(unsigned N) { MDValuePtrs.resize(N); }
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
void push_back(Metadata *MD) { MDValuePtrs.emplace_back(MD); }
|
2009-08-04 06:00:18 +00:00
|
|
|
void clear() { MDValuePtrs.clear(); }
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
Metadata *back() const { return MDValuePtrs.back(); }
|
2009-08-04 06:00:18 +00:00
|
|
|
void pop_back() { MDValuePtrs.pop_back(); }
|
|
|
|
bool empty() const { return MDValuePtrs.empty(); }
|
2012-11-25 15:23:39 +00:00
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
Metadata *operator[](unsigned i) const {
|
2009-08-04 06:00:18 +00:00
|
|
|
assert(i < MDValuePtrs.size());
|
|
|
|
return MDValuePtrs[i];
|
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2009-08-04 06:00:18 +00:00
|
|
|
void shrinkTo(unsigned N) {
|
|
|
|
assert(N <= size() && "Invalid shrinkTo request!");
|
|
|
|
MDValuePtrs.resize(N);
|
|
|
|
}
|
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
Metadata *getValueFwdRef(unsigned Idx);
|
|
|
|
void AssignValue(Metadata *MD, unsigned Idx);
|
|
|
|
void tryToResolveCycles();
|
2009-08-04 06:00:18 +00:00
|
|
|
};
|
|
|
|
|
2013-09-11 18:05:11 +00:00
|
|
|
class BitcodeReader : public GVMaterializer {
|
2009-10-28 05:53:48 +00:00
|
|
|
LLVMContext &Context;
|
2015-01-10 00:07:30 +00:00
|
|
|
DiagnosticHandlerFunction DiagnosticHandler;
|
2010-01-27 20:34:15 +00:00
|
|
|
Module *TheModule;
|
2014-06-23 21:53:12 +00:00
|
|
|
std::unique_ptr<MemoryBuffer> Buffer;
|
2014-03-06 05:51:42 +00:00
|
|
|
std::unique_ptr<BitstreamReader> StreamFile;
|
2009-04-26 20:59:02 +00:00
|
|
|
BitstreamCursor Stream;
|
2012-02-06 22:30:29 +00:00
|
|
|
DataStreamer *LazyStreamer;
|
|
|
|
uint64_t NextUnreadBit;
|
|
|
|
bool SeenValueSymbolTable;
|
2012-11-25 15:23:39 +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
|
|
|
std::vector<Type*> TypeList;
|
2007-04-24 05:48:56 +00:00
|
|
|
BitcodeReaderValueList ValueList;
|
2009-08-04 06:00:18 +00:00
|
|
|
BitcodeReaderMDValueList MDValueList;
|
2014-06-27 18:19:56 +00:00
|
|
|
std::vector<Comdat *> ComdatList;
|
2009-09-18 19:26:43 +00:00
|
|
|
SmallVector<Instruction *, 64> InstructionList;
|
|
|
|
|
2007-04-24 03:30:34 +00:00
|
|
|
std::vector<std::pair<GlobalVariable*, unsigned> > GlobalInits;
|
2007-04-26 02:46:40 +00:00
|
|
|
std::vector<std::pair<GlobalAlias*, unsigned> > AliasInits;
|
2013-09-16 01:08:15 +00:00
|
|
|
std::vector<std::pair<Function*, unsigned> > FunctionPrefixes;
|
2014-12-03 02:08:38 +00:00
|
|
|
std::vector<std::pair<Function*, unsigned> > FunctionPrologues;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2013-09-28 00:22:27 +00:00
|
|
|
SmallVector<Instruction*, 64> InstsWithTBAATag;
|
|
|
|
|
2008-09-26 22:53:05 +00:00
|
|
|
/// MAttributes - The set of attributes by index. Index zero in the
|
2007-05-04 03:30:17 +00:00
|
|
|
/// file is for null, and is thus not represented here. As such all indices
|
|
|
|
/// are off by one.
|
2012-12-07 23:16:57 +00:00
|
|
|
std::vector<AttributeSet> MAttributes;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2013-02-10 23:24:25 +00:00
|
|
|
/// \brief The set of attribute groups.
|
2013-02-11 22:32:29 +00:00
|
|
|
std::map<unsigned, AttributeSet> MAttributeGroups;
|
2013-02-10 23:24:25 +00:00
|
|
|
|
2007-05-01 05:52:21 +00:00
|
|
|
/// FunctionBBs - While parsing a function body, this is a list of the basic
|
|
|
|
/// blocks for the function.
|
|
|
|
std::vector<BasicBlock*> FunctionBBs;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2007-05-01 04:59:48 +00:00
|
|
|
// When reading the module header, this list is populated with functions that
|
|
|
|
// have bodies later in the file.
|
|
|
|
std::vector<Function*> FunctionsWithBodies;
|
2007-08-04 01:51:18 +00:00
|
|
|
|
2012-11-25 15:23:39 +00:00
|
|
|
// When intrinsic functions are encountered which require upgrading they are
|
2007-08-04 01:51:18 +00:00
|
|
|
// stored here with their replacement function.
|
|
|
|
typedef std::vector<std::pair<Function*, Function*> > UpgradedIntrinsicMap;
|
|
|
|
UpgradedIntrinsicMap UpgradedIntrinsics;
|
2010-07-20 21:42:28 +00:00
|
|
|
|
|
|
|
// Map the bitcode's custom MDKind ID to the Module's MDKind ID.
|
|
|
|
DenseMap<unsigned, unsigned> MDKindMap;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2012-02-06 22:30:29 +00:00
|
|
|
// Several operations happen after the module header has been read, but
|
|
|
|
// before function bodies are processed. This keeps track of whether
|
|
|
|
// we've done this yet.
|
|
|
|
bool SeenFirstFunctionBody;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2007-05-01 04:59:48 +00:00
|
|
|
/// DeferredFunctionInfo - When function bodies are initially scanned, this
|
2010-01-27 20:34:15 +00:00
|
|
|
/// map contains info about where to find deferred function body in the
|
|
|
|
/// stream.
|
|
|
|
DenseMap<Function*, uint64_t> DeferredFunctionInfo;
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2014-08-01 21:51:52 +00:00
|
|
|
/// These are basic blocks forward-referenced by block addresses. They are
|
2014-08-16 01:54:37 +00:00
|
|
|
/// inserted lazily into functions when they're loaded. The basic block ID is
|
|
|
|
/// its index into the vector.
|
|
|
|
DenseMap<Function *, std::vector<BasicBlock *>> BasicBlockFwdRefs;
|
2014-08-05 17:49:48 +00:00
|
|
|
std::deque<Function *> BasicBlockFwdRefQueue;
|
2010-09-13 18:00:48 +00:00
|
|
|
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
/// UseRelativeIDs - Indicates that we are using a new encoding for
|
2012-10-11 21:45:16 +00:00
|
|
|
/// instruction operands where most operands in the current
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
/// FUNCTION_BLOCK are encoded relative to the instruction number,
|
|
|
|
/// for a more compact encoding. Some instruction operands are not
|
|
|
|
/// relative to the instruction ID: basic block numbers, and types.
|
|
|
|
/// Once the old style function blocks have been phased out, we would
|
|
|
|
/// not need this flag.
|
|
|
|
bool UseRelativeIDs;
|
|
|
|
|
2014-08-01 21:11:34 +00:00
|
|
|
/// True if all functions will be materialized, negating the need to process
|
|
|
|
/// (e.g.) blockaddress forward references.
|
|
|
|
bool WillMaterializeAllForwardRefs;
|
|
|
|
|
|
|
|
/// Functions that have block addresses taken. This is usually empty.
|
|
|
|
SmallPtrSet<const Function *, 4> BlockAddressesTaken;
|
|
|
|
|
2007-04-22 06:23:29 +00:00
|
|
|
public:
|
2015-01-10 00:07:30 +00:00
|
|
|
std::error_code Error(BitcodeError E, const Twine &Message);
|
|
|
|
std::error_code Error(BitcodeError E);
|
|
|
|
std::error_code Error(const Twine &Message);
|
|
|
|
|
|
|
|
explicit BitcodeReader(MemoryBuffer *buffer, LLVMContext &C,
|
|
|
|
DiagnosticHandlerFunction DiagnosticHandler);
|
|
|
|
explicit BitcodeReader(DataStreamer *streamer, LLVMContext &C,
|
|
|
|
DiagnosticHandlerFunction DiagnosticHandler);
|
2014-06-18 18:26:53 +00:00
|
|
|
~BitcodeReader() { FreeState(); }
|
2012-01-02 07:49:53 +00:00
|
|
|
|
2014-08-01 21:11:34 +00:00
|
|
|
std::error_code materializeForwardReferencedFunctions();
|
2012-01-02 07:49:53 +00:00
|
|
|
|
2007-05-18 04:02:46 +00:00
|
|
|
void FreeState();
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2014-08-26 21:49:01 +00:00
|
|
|
void releaseBuffer();
|
2014-06-18 20:07:35 +00:00
|
|
|
|
2014-03-05 07:52:44 +00:00
|
|
|
bool isDematerializable(const GlobalValue *GV) const override;
|
2014-10-24 22:50:48 +00:00
|
|
|
std::error_code materialize(GlobalValue *GV) override;
|
2014-06-13 01:25:41 +00:00
|
|
|
std::error_code MaterializeModule(Module *M) override;
|
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
|
|
|
std::vector<StructType *> getIdentifiedStructTypes() const override;
|
2014-03-05 07:52:44 +00:00
|
|
|
void Dematerialize(GlobalValue *GV) override;
|
2007-05-15 06:29:44 +00:00
|
|
|
|
2007-04-22 06:23:29 +00:00
|
|
|
/// @brief Main interface to parsing a bitcode buffer.
|
|
|
|
/// @returns true if an error occurred.
|
2014-06-13 01:25:41 +00:00
|
|
|
std::error_code ParseBitcodeInto(Module *M);
|
2010-10-06 01:22:42 +00:00
|
|
|
|
|
|
|
/// @brief Cheap mechanism to just extract module triple
|
|
|
|
/// @returns true if an error occurred.
|
2014-07-04 20:02:42 +00:00
|
|
|
ErrorOr<std::string> parseTriple();
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
|
|
|
|
static uint64_t decodeSignRotatedValue(uint64_t V);
|
|
|
|
|
2007-04-22 06:23:29 +00:00
|
|
|
private:
|
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
|
|
|
std::vector<StructType *> IdentifiedStructTypes;
|
|
|
|
StructType *createIdentifiedStructType(LLVMContext &Context, StringRef Name);
|
|
|
|
StructType *createIdentifiedStructType(LLVMContext &Context);
|
|
|
|
|
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
|
|
|
Type *getTypeByID(unsigned ID);
|
2011-07-18 04:54:35 +00:00
|
|
|
Value *getFnValueByID(unsigned ID, Type *Ty) {
|
2011-07-07 05:29:18 +00:00
|
|
|
if (Ty && Ty->isMetadataTy())
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
return MetadataAsValue::get(Ty->getContext(), getFnMetadataByID(ID));
|
2011-07-07 05:12:37 +00:00
|
|
|
return ValueList.getValueFwdRef(ID, Ty);
|
2007-05-01 07:01:57 +00:00
|
|
|
}
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
|
|
|
Metadata *getFnMetadataByID(unsigned ID) {
|
|
|
|
return MDValueList.getValueFwdRef(ID);
|
|
|
|
}
|
2007-05-02 05:46:45 +00:00
|
|
|
BasicBlock *getBasicBlock(unsigned ID) const {
|
2014-04-28 04:05:08 +00:00
|
|
|
if (ID >= FunctionBBs.size()) return nullptr; // Invalid ID
|
2007-05-02 05:46:45 +00:00
|
|
|
return FunctionBBs[ID];
|
|
|
|
}
|
2012-12-07 23:16:57 +00:00
|
|
|
AttributeSet getAttributes(unsigned i) const {
|
2008-09-26 22:53:05 +00:00
|
|
|
if (i-1 < MAttributes.size())
|
|
|
|
return MAttributes[i-1];
|
2012-12-07 23:16:57 +00:00
|
|
|
return AttributeSet();
|
2007-05-04 03:30:17 +00:00
|
|
|
}
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2007-05-06 00:00:00 +00:00
|
|
|
/// getValueTypePair - Read a value/type pair out of the specified record from
|
|
|
|
/// slot 'Slot'. Increment Slot past the number of slots used in the record.
|
|
|
|
/// Return true on failure.
|
2013-07-11 16:22:38 +00:00
|
|
|
bool getValueTypePair(SmallVectorImpl<uint64_t> &Record, unsigned &Slot,
|
2007-05-06 00:00:00 +00:00
|
|
|
unsigned InstNum, Value *&ResVal) {
|
|
|
|
if (Slot == Record.size()) return true;
|
2007-05-06 03:23:14 +00:00
|
|
|
unsigned ValNo = (unsigned)Record[Slot++];
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
// Adjust the ValNo, if it was encoded relative to the InstNum.
|
|
|
|
if (UseRelativeIDs)
|
|
|
|
ValNo = InstNum - ValNo;
|
2007-05-06 00:00:00 +00:00
|
|
|
if (ValNo < InstNum) {
|
|
|
|
// If this is not a forward reference, just return the value we already
|
|
|
|
// have.
|
2014-04-28 04:05:08 +00:00
|
|
|
ResVal = getFnValueByID(ValNo, nullptr);
|
|
|
|
return ResVal == nullptr;
|
2007-05-06 00:00:00 +00:00
|
|
|
} else if (Slot == Record.size()) {
|
|
|
|
return true;
|
|
|
|
}
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
|
2007-05-06 03:23:14 +00:00
|
|
|
unsigned TypeNo = (unsigned)Record[Slot++];
|
2007-05-06 00:00:00 +00:00
|
|
|
ResVal = getFnValueByID(ValNo, getTypeByID(TypeNo));
|
2014-04-28 04:05:08 +00:00
|
|
|
return ResVal == nullptr;
|
2007-05-06 00:00:00 +00:00
|
|
|
}
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
|
|
|
|
/// popValue - Read a value out of the specified record from slot 'Slot'.
|
|
|
|
/// Increment Slot past the number of slots used by the value in the record.
|
|
|
|
/// Return true if there is an error.
|
2013-07-11 16:22:38 +00:00
|
|
|
bool popValue(SmallVectorImpl<uint64_t> &Record, unsigned &Slot,
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned InstNum, Type *Ty, Value *&ResVal) {
|
|
|
|
if (getValue(Record, Slot, InstNum, Ty, ResVal))
|
|
|
|
return true;
|
|
|
|
// All values currently take a single record slot.
|
|
|
|
++Slot;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getValue -- Like popValue, but does not increment the Slot number.
|
2013-07-11 16:22:38 +00:00
|
|
|
bool getValue(SmallVectorImpl<uint64_t> &Record, unsigned Slot,
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned InstNum, Type *Ty, Value *&ResVal) {
|
|
|
|
ResVal = getValue(Record, Slot, InstNum, Ty);
|
2014-04-28 04:05:08 +00:00
|
|
|
return ResVal == nullptr;
|
2007-05-06 00:00:00 +00:00
|
|
|
}
|
2007-05-04 03:30:17 +00:00
|
|
|
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
/// getValue -- Version of getValue that returns ResVal directly,
|
|
|
|
/// or 0 if there is an error.
|
2013-07-11 16:22:38 +00:00
|
|
|
Value *getValue(SmallVectorImpl<uint64_t> &Record, unsigned Slot,
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned InstNum, Type *Ty) {
|
2014-04-28 04:05:08 +00:00
|
|
|
if (Slot == Record.size()) return nullptr;
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned ValNo = (unsigned)Record[Slot];
|
|
|
|
// Adjust the ValNo, if it was encoded relative to the InstNum.
|
|
|
|
if (UseRelativeIDs)
|
|
|
|
ValNo = InstNum - ValNo;
|
|
|
|
return getFnValueByID(ValNo, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getValueSigned -- Like getValue, but decodes signed VBRs.
|
2013-07-11 16:22:38 +00:00
|
|
|
Value *getValueSigned(SmallVectorImpl<uint64_t> &Record, unsigned Slot,
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned InstNum, Type *Ty) {
|
2014-04-28 04:05:08 +00:00
|
|
|
if (Slot == Record.size()) return nullptr;
|
Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position. The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.
I.e., Instead of having:
... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2
it will now be roughly:
... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2
This makes it so that ids remain relatively small and can be encoded
in fewer bits.
With this encoding, forward reference operands will be given
negative-valued IDs. Use signed VBRs for the most common case
of forward references, which is phi instructions.
To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165739 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 20:20:40 +00:00
|
|
|
unsigned ValNo = (unsigned)decodeSignRotatedValue(Record[Slot]);
|
|
|
|
// Adjust the ValNo, if it was encoded relative to the InstNum.
|
|
|
|
if (UseRelativeIDs)
|
|
|
|
ValNo = InstNum - ValNo;
|
|
|
|
return getFnValueByID(ValNo, Ty);
|
|
|
|
}
|
|
|
|
|
2014-06-13 01:25:41 +00:00
|
|
|
std::error_code ParseAttrKind(uint64_t Code, Attribute::AttrKind *Kind);
|
|
|
|
std::error_code ParseModule(bool Resume);
|
|
|
|
std::error_code ParseAttributeBlock();
|
|
|
|
std::error_code ParseAttributeGroupBlock();
|
|
|
|
std::error_code ParseTypeTable();
|
|
|
|
std::error_code ParseTypeTableBody();
|
|
|
|
|
|
|
|
std::error_code ParseValueSymbolTable();
|
|
|
|
std::error_code ParseConstants();
|
|
|
|
std::error_code RememberAndSkipFunctionBody();
|
|
|
|
std::error_code ParseFunctionBody(Function *F);
|
|
|
|
std::error_code GlobalCleanup();
|
|
|
|
std::error_code ResolveGlobalAndAliasInits();
|
|
|
|
std::error_code ParseMetadata();
|
|
|
|
std::error_code ParseMetadataAttachment();
|
2014-07-04 20:02:42 +00:00
|
|
|
ErrorOr<std::string> parseModuleTriple();
|
2014-06-13 01:25:41 +00:00
|
|
|
std::error_code ParseUseLists();
|
|
|
|
std::error_code InitStream();
|
|
|
|
std::error_code InitStreamFromBuffer();
|
|
|
|
std::error_code InitLazyStream();
|
|
|
|
std::error_code FindFunctionInStream(
|
|
|
|
Function *F,
|
|
|
|
DenseMap<Function *, uint64_t>::iterator DeferredFunctionInfoIterator);
|
2007-04-22 06:23:29 +00:00
|
|
|
};
|
2012-11-25 15:23:39 +00:00
|
|
|
|
2007-04-22 06:23:29 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
|
|
|
#endif
|