RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:32:44 +01:00
Code Issues Projects Releases Wiki Activity
b7fc1f8c1c
llvm-mirror/unittests/IR/MDBuilderTest.cpp

108 lines
4.0 KiB
C++
Raw Normal View History

Move llvm/Support/MDBuilder.h to llvm/MDBuilder.h, to live with IRBuilder, DIBuilder, etc. This is the proper layering as MDBuilder can't be used (or implemented) without the Core Metadata representation. Patches to Clang and Dragonegg coming up. llvm-svn: 160237
2012-07-16 01:26:50 +02:00
//===- llvm/unittests/MDBuilderTest.cpp - MDBuilder unit tests ------------===//
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 09:50:56 +01:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
//
//===----------------------------------------------------------------------===//
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 12:36:10 +01:00
#include "llvm/IR/MDBuilder.h"
#include "llvm/IR/IRBuilder.h"
Move MDBuilder's methods out of line. Making them inline was a historical accident, they're neither hot nor templated. llvm-svn: 206109
2014-04-12 16:26:59 +02:00
#include "llvm/IR/Metadata.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 12:36:10 +01:00
#include "llvm/IR/Operator.h"
Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.h This was always part of the VMCore library out of necessity -- it deals entirely in the IR. The .cpp file in fact was already part of the VMCore library. This is just a mechanical move. I've tried to go through and re-apply the coding standard's preferred header sort, but at 40-ish files, I may have gotten some wrong. Please let me know if so. I'll be committing the corresponding updates to Clang and Polly, and Duncan has DragonEgg. Thanks to Bill and Eric for giving the green light for this bit of cleanup. llvm-svn: 159421
2012-06-29 14:38:19 +02:00
#include "gtest/gtest.h"
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
using namespace llvm;
namespace {
class MDBuilderTest : public testing::Test {
protected:
LLVMContext Context;
};
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
TEST_F(MDBuilderTest, createString) {
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
MDBuilder MDHelper(Context);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
MDString *Str0 = MDHelper.createString("");
MDString *Str1 = MDHelper.createString("string");
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_EQ(Str0->getString(), StringRef(""));
EXPECT_EQ(Str1->getString(), StringRef("string"));
}
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
TEST_F(MDBuilderTest, createFPMath) {
MDBuilder MDHelper(Context);
MDNode *MD0 = MDHelper.createFPMath(0.0);
MDNode *MD1 = MDHelper.createFPMath(1.0);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 00:29:17 +02:00
EXPECT_EQ(MD0, (MDNode *)nullptr);
EXPECT_NE(MD1, (MDNode *)nullptr);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
EXPECT_EQ(MD1->getNumOperands(), 1U);
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.) llvm-svn: 223802
2014-12-09 19:38:53 +01:00
Metadata *Op = MD1->getOperand(0);
EXPECT_TRUE(mdconst::hasa<ConstantFP>(Op));
ConstantFP *Val = mdconst::extract<ConstantFP>(Op);
EXPECT_TRUE(Val->getType()->isFloatingPointTy());
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
EXPECT_TRUE(Val->isExactlyValue(1.0));
}
TEST_F(MDBuilderTest, createRangeMetadata) {
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
MDBuilder MDHelper(Context);
APInt A(8, 1), B(8, 2);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
MDNode *R0 = MDHelper.createRange(A, A);
MDNode *R1 = MDHelper.createRange(A, B);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 00:29:17 +02:00
EXPECT_EQ(R0, (MDNode *)nullptr);
EXPECT_NE(R1, (MDNode *)nullptr);
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_EQ(R1->getNumOperands(), 2U);
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.) llvm-svn: 223802
2014-12-09 19:38:53 +01:00
EXPECT_TRUE(mdconst::hasa<ConstantInt>(R1->getOperand(0)));
EXPECT_TRUE(mdconst::hasa<ConstantInt>(R1->getOperand(1)));
ConstantInt *C0 = mdconst::extract<ConstantInt>(R1->getOperand(0));
ConstantInt *C1 = mdconst::extract<ConstantInt>(R1->getOperand(1));
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_EQ(C0->getValue(), A);
EXPECT_EQ(C1->getValue(), B);
}
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
TEST_F(MDBuilderTest, createAnonymousTBAARoot) {
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
MDBuilder MDHelper(Context);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
MDNode *R0 = MDHelper.createAnonymousTBAARoot();
MDNode *R1 = MDHelper.createAnonymousTBAARoot();
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_NE(R0, R1);
EXPECT_GE(R0->getNumOperands(), 1U);
EXPECT_GE(R1->getNumOperands(), 1U);
EXPECT_EQ(R0->getOperand(0), R0);
EXPECT_EQ(R1->getOperand(0), R1);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 00:29:17 +02:00
EXPECT_TRUE(R0->getNumOperands() == 1 || R0->getOperand(1) == nullptr);
EXPECT_TRUE(R1->getNumOperands() == 1 || R1->getOperand(1) == nullptr);
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
}
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
TEST_F(MDBuilderTest, createTBAARoot) {
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
MDBuilder MDHelper(Context);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
MDNode *R0 = MDHelper.createTBAARoot("Root");
MDNode *R1 = MDHelper.createTBAARoot("Root");
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_EQ(R0, R1);
EXPECT_GE(R0->getNumOperands(), 1U);
EXPECT_TRUE(isa<MDString>(R0->getOperand(0)));
EXPECT_EQ(cast<MDString>(R0->getOperand(0))->getString(), "Root");
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 00:29:17 +02:00
EXPECT_TRUE(R0->getNumOperands() == 1 || R0->getOperand(1) == nullptr);
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
}
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
TEST_F(MDBuilderTest, createTBAANode) {
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
MDBuilder MDHelper(Context);
Make it possible to indicate relaxed floating point requirements at the IR level through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
2012-04-16 18:28:59 +02:00
MDNode *R = MDHelper.createTBAARoot("Root");
MDNode *N0 = MDHelper.createTBAANode("Node", R);
MDNode *N1 = MDHelper.createTBAANode("edoN", R);
MDNode *N2 = MDHelper.createTBAANode("Node", R, true);
MDNode *N3 = MDHelper.createTBAANode("Node", R);
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
EXPECT_EQ(N0, N3);
EXPECT_NE(N0, N1);
EXPECT_NE(N0, N2);
EXPECT_GE(N0->getNumOperands(), 2U);
EXPECT_GE(N1->getNumOperands(), 2U);
EXPECT_GE(N2->getNumOperands(), 3U);
EXPECT_TRUE(isa<MDString>(N0->getOperand(0)));
EXPECT_TRUE(isa<MDString>(N1->getOperand(0)));
EXPECT_TRUE(isa<MDString>(N2->getOperand(0)));
EXPECT_EQ(cast<MDString>(N0->getOperand(0))->getString(), "Node");
EXPECT_EQ(cast<MDString>(N1->getOperand(0))->getString(), "edoN");
EXPECT_EQ(cast<MDString>(N2->getOperand(0))->getString(), "Node");
EXPECT_EQ(N0->getOperand(1), R);
EXPECT_EQ(N1->getOperand(1), R);
EXPECT_EQ(N2->getOperand(1), R);
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.) llvm-svn: 223802
2014-12-09 19:38:53 +01:00
EXPECT_TRUE(mdconst::hasa<ConstantInt>(N2->getOperand(2)));
EXPECT_EQ(mdconst::extract<ConstantInt>(N2->getOperand(2))->getZExtValue(),
1U);
Add the MDBuilder helper class for conveniently creating metadata. llvm-svn: 154766
2012-04-15 20:03:49 +02:00
}
}
Reference in New Issue Copy Permalink