2015-03-17 09:14:40 +08:00
|
|
|
//===- ValueMapper.cpp - Unit tests for ValueMapper -----------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-06-06 19:06:56 +08:00
|
|
|
#include "llvm/Transforms/Utils/ValueMapper.h"
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2016-04-07 09:08:39 +08:00
|
|
|
#include "llvm/IR/Function.h"
|
2016-04-14 06:54:01 +08:00
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
2015-03-17 09:14:40 +08:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/Metadata.h"
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNode) {
|
ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
2016-04-06 04:23:21 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *U = MDTuple::get(Context, None);
|
|
|
|
|
|
|
|
// The node should be unchanged.
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(U, ValueMapper(VM).mapMDNode(*U));
|
ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
2016-04-06 04:23:21 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeCycle) {
|
ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
2016-04-06 04:23:21 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
MDNode *U0;
|
|
|
|
MDNode *U1;
|
|
|
|
{
|
|
|
|
Metadata *Ops[] = {nullptr};
|
|
|
|
auto T = MDTuple::getTemporary(Context, Ops);
|
|
|
|
Ops[0] = T.get();
|
|
|
|
U0 = MDTuple::get(Context, Ops);
|
|
|
|
T->replaceOperandWith(0, U0);
|
|
|
|
U1 = MDNode::replaceWithUniqued(std::move(T));
|
|
|
|
U0->resolveCycles();
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPECT_TRUE(U0->isResolved());
|
|
|
|
EXPECT_TRUE(U0->isUniqued());
|
|
|
|
EXPECT_TRUE(U1->isResolved());
|
|
|
|
EXPECT_TRUE(U1->isUniqued());
|
|
|
|
EXPECT_EQ(U1, U0->getOperand(0));
|
|
|
|
EXPECT_EQ(U0, U1->getOperand(0));
|
|
|
|
|
|
|
|
// Cycles shouldn't be duplicated.
|
|
|
|
{
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(U0, ValueMapper(VM).mapMDNode(*U0));
|
|
|
|
EXPECT_EQ(U1, ValueMapper(VM).mapMDNode(*U1));
|
ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
2016-04-06 04:23:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check the other order.
|
|
|
|
{
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(U1, ValueMapper(VM).mapMDNode(*U1));
|
|
|
|
EXPECT_EQ(U0, ValueMapper(VM).mapMDNode(*U0));
|
ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
2016-04-06 04:23:21 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeDuplicatedCycle) {
|
2016-04-14 06:54:01 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *PtrTy = Type::getInt8Ty(Context)->getPointerTo();
|
|
|
|
std::unique_ptr<GlobalVariable> G0 = llvm::make_unique<GlobalVariable>(
|
|
|
|
PtrTy, false, GlobalValue::ExternalLinkage, nullptr, "G0");
|
|
|
|
std::unique_ptr<GlobalVariable> G1 = llvm::make_unique<GlobalVariable>(
|
|
|
|
PtrTy, false, GlobalValue::ExternalLinkage, nullptr, "G1");
|
|
|
|
|
|
|
|
// Create a cycle that references G0.
|
|
|
|
MDNode *N0; // !0 = !{!1}
|
|
|
|
MDNode *N1; // !1 = !{!0, i8* @G0}
|
|
|
|
{
|
|
|
|
auto T0 = MDTuple::getTemporary(Context, nullptr);
|
|
|
|
Metadata *Ops1[] = {T0.get(), ConstantAsMetadata::get(G0.get())};
|
|
|
|
N1 = MDTuple::get(Context, Ops1);
|
|
|
|
T0->replaceOperandWith(0, N1);
|
|
|
|
N0 = MDNode::replaceWithUniqued(std::move(T0));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Resolve N0 and N1.
|
|
|
|
ASSERT_FALSE(N0->isResolved());
|
|
|
|
ASSERT_FALSE(N1->isResolved());
|
|
|
|
N0->resolveCycles();
|
|
|
|
ASSERT_TRUE(N0->isResolved());
|
|
|
|
ASSERT_TRUE(N1->isResolved());
|
|
|
|
|
|
|
|
// Seed the value map to map G0 to G1 and map the nodes. The output should
|
|
|
|
// have new nodes that reference G1 (instead of G0).
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
VM[G0.get()] = G1.get();
|
2016-04-16 10:29:55 +08:00
|
|
|
MDNode *MappedN0 = ValueMapper(VM).mapMDNode(*N0);
|
|
|
|
MDNode *MappedN1 = ValueMapper(VM).mapMDNode(*N1);
|
2016-04-14 06:54:01 +08:00
|
|
|
EXPECT_NE(N0, MappedN0);
|
|
|
|
EXPECT_NE(N1, MappedN1);
|
|
|
|
EXPECT_EQ(ConstantAsMetadata::get(G1.get()), MappedN1->getOperand(1));
|
|
|
|
|
|
|
|
// Check that the output nodes are resolved.
|
|
|
|
EXPECT_TRUE(MappedN0->isResolved());
|
|
|
|
EXPECT_TRUE(MappedN1->isResolved());
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeUnresolved) {
|
2015-03-17 09:14:40 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
TempMDTuple T = MDTuple::getTemporary(Context, None);
|
|
|
|
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(T.get(), ValueMapper(VM, RF_NoModuleLevelChanges).mapMDNode(*T));
|
2015-03-17 09:14:40 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeDistinct) {
|
2015-08-04 01:09:38 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *D = MDTuple::getDistinct(Context, None);
|
|
|
|
|
|
|
|
{
|
|
|
|
// The node should be cloned.
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_NE(D, ValueMapper(VM).mapMDNode(*D));
|
2015-08-04 01:09:38 +08:00
|
|
|
}
|
|
|
|
{
|
|
|
|
// The node should be moved.
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(D, ValueMapper(VM, RF_MoveDistinctMDs).mapMDNode(*D));
|
2015-08-04 01:09:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeDistinctOperands) {
|
2015-08-04 01:09:38 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
Metadata *Old = MDTuple::getDistinct(Context, None);
|
|
|
|
auto *D = MDTuple::getDistinct(Context, Old);
|
|
|
|
ASSERT_EQ(Old, D->getOperand(0));
|
|
|
|
|
|
|
|
Metadata *New = MDTuple::getDistinct(Context, None);
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
VM.MD()[Old].reset(New);
|
|
|
|
|
|
|
|
// Make sure operands are updated.
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(D, ValueMapper(VM, RF_MoveDistinctMDs).mapMDNode(*D));
|
2015-08-04 01:09:38 +08:00
|
|
|
EXPECT_EQ(New, D->getOperand(0));
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeSeeded) {
|
2016-04-03 01:04:38 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *D = MDTuple::getDistinct(Context, None);
|
|
|
|
|
|
|
|
// The node should be moved.
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
EXPECT_EQ(None, VM.getMappedMD(D));
|
|
|
|
|
|
|
|
VM.MD().insert(std::make_pair(D, TrackingMDRef(D)));
|
|
|
|
EXPECT_EQ(D, *VM.getMappedMD(D));
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(D, ValueMapper(VM).mapMDNode(*D));
|
2016-04-03 01:04:38 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMDNodeSeededWithNull) {
|
2016-04-03 01:04:38 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *D = MDTuple::getDistinct(Context, None);
|
|
|
|
|
|
|
|
// The node should be moved.
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
EXPECT_EQ(None, VM.getMappedMD(D));
|
|
|
|
|
|
|
|
VM.MD().insert(std::make_pair(D, TrackingMDRef()));
|
|
|
|
EXPECT_EQ(nullptr, *VM.getMappedMD(D));
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(nullptr, ValueMapper(VM).mapMDNode(*D));
|
2016-04-03 01:04:38 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataNullMapGlobalWithIgnoreMissingLocals) {
|
2016-04-07 09:22:45 +08:00
|
|
|
LLVMContext C;
|
|
|
|
FunctionType *FTy =
|
|
|
|
FunctionType::get(Type::getVoidTy(C), Type::getInt8Ty(C), false);
|
|
|
|
std::unique_ptr<Function> F(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F"));
|
|
|
|
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
RemapFlags Flags = RF_IgnoreMissingLocals | RF_NullMapMissingGlobalValues;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(nullptr, ValueMapper(VM, Flags).mapValue(*F));
|
2016-04-07 09:22:45 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataMDString) {
|
2016-04-09 02:47:02 +08:00
|
|
|
LLVMContext C;
|
|
|
|
auto *S1 = MDString::get(C, "S1");
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
|
|
|
|
// Make sure S1 maps to itself, but isn't memoized.
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(S1, ValueMapper(VM).mapMetadata(*S1));
|
2016-04-09 02:47:02 +08:00
|
|
|
EXPECT_EQ(None, VM.getMappedMD(S1));
|
|
|
|
|
|
|
|
// We still expect VM.MD() to be respected.
|
|
|
|
auto *S2 = MDString::get(C, "S2");
|
|
|
|
VM.MD()[S1].reset(S2);
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(S2, ValueMapper(VM).mapMetadata(*S1));
|
2016-04-09 02:47:02 +08:00
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataGetMappedMD) {
|
2016-04-09 02:49:36 +08:00
|
|
|
LLVMContext C;
|
|
|
|
auto *N0 = MDTuple::get(C, None);
|
|
|
|
auto *N1 = MDTuple::get(C, N0);
|
|
|
|
|
|
|
|
// Make sure hasMD and getMappedMD work correctly.
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
EXPECT_FALSE(VM.hasMD());
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(N0, ValueMapper(VM).mapMetadata(*N0));
|
|
|
|
EXPECT_EQ(N1, ValueMapper(VM).mapMetadata(*N1));
|
2016-04-09 02:49:36 +08:00
|
|
|
EXPECT_TRUE(VM.hasMD());
|
|
|
|
ASSERT_NE(None, VM.getMappedMD(N0));
|
|
|
|
ASSERT_NE(None, VM.getMappedMD(N1));
|
|
|
|
EXPECT_EQ(N0, *VM.getMappedMD(N0));
|
|
|
|
EXPECT_EQ(N1, *VM.getMappedMD(N1));
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataNoModuleLevelChanges) {
|
2016-04-09 02:49:36 +08:00
|
|
|
LLVMContext C;
|
|
|
|
auto *N0 = MDTuple::get(C, None);
|
|
|
|
auto *N1 = MDTuple::get(C, N0);
|
|
|
|
|
|
|
|
// Nothing should be memoized when RF_NoModuleLevelChanges.
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
EXPECT_FALSE(VM.hasMD());
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(N0, ValueMapper(VM, RF_NoModuleLevelChanges).mapMetadata(*N0));
|
|
|
|
EXPECT_EQ(N1, ValueMapper(VM, RF_NoModuleLevelChanges).mapMetadata(*N1));
|
2016-04-09 02:49:36 +08:00
|
|
|
EXPECT_FALSE(VM.hasMD());
|
|
|
|
EXPECT_EQ(None, VM.getMappedMD(N0));
|
|
|
|
EXPECT_EQ(None, VM.getMappedMD(N1));
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataConstantAsMetadata) {
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
LLVMContext C;
|
|
|
|
FunctionType *FTy =
|
|
|
|
FunctionType::get(Type::getVoidTy(C), Type::getInt8Ty(C), false);
|
|
|
|
std::unique_ptr<Function> F(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F"));
|
|
|
|
|
|
|
|
auto *CAM = ConstantAsMetadata::get(F.get());
|
|
|
|
{
|
2016-04-16 11:39:44 +08:00
|
|
|
// ConstantAsMetadata shouldn't be memoized.
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(CAM, ValueMapper(VM).mapMetadata(*CAM));
|
2016-04-16 11:39:44 +08:00
|
|
|
EXPECT_FALSE(VM.MD().count(CAM));
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(CAM, ValueMapper(VM, RF_IgnoreMissingLocals).mapMetadata(*CAM));
|
2016-04-16 11:39:44 +08:00
|
|
|
EXPECT_FALSE(VM.MD().count(CAM));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
|
2016-04-16 11:39:44 +08:00
|
|
|
// But it should respect a mapping that gets seeded.
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
auto *N = MDTuple::get(C, None);
|
|
|
|
VM.MD()[CAM].reset(N);
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(N, ValueMapper(VM).mapMetadata(*CAM));
|
|
|
|
EXPECT_EQ(N, ValueMapper(VM, RF_IgnoreMissingLocals).mapMetadata(*CAM));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<Function> F2(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F2"));
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
VM[F.get()] = F2.get();
|
2016-04-16 10:29:55 +08:00
|
|
|
auto *F2MD = ValueMapper(VM).mapMetadata(*CAM);
|
2016-04-16 11:39:44 +08:00
|
|
|
EXPECT_FALSE(VM.MD().count(CAM));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
EXPECT_TRUE(F2MD);
|
|
|
|
EXPECT_EQ(F2.get(), cast<ConstantAsMetadata>(F2MD)->getValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef GTEST_HAS_DEATH_TEST
|
|
|
|
#ifndef NDEBUG
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapMetadataLocalAsMetadata) {
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
LLVMContext C;
|
|
|
|
FunctionType *FTy =
|
|
|
|
FunctionType::get(Type::getVoidTy(C), Type::getInt8Ty(C), false);
|
|
|
|
std::unique_ptr<Function> F(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F"));
|
|
|
|
Argument &A = *F->arg_begin();
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
// mapMetadata doesn't support LocalAsMetadata. The only valid container for
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
// LocalAsMetadata is a MetadataAsValue instance, so use it directly.
|
|
|
|
auto *LAM = LocalAsMetadata::get(&A);
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_DEATH(ValueMapper(VM).mapMetadata(*LAM), "Unexpected local metadata");
|
|
|
|
EXPECT_DEATH(ValueMapper(VM, RF_IgnoreMissingLocals).mapMetadata(*LAM),
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
"Unexpected local metadata");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapValueLocalAsMetadata) {
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
LLVMContext C;
|
|
|
|
FunctionType *FTy =
|
|
|
|
FunctionType::get(Type::getVoidTy(C), Type::getInt8Ty(C), false);
|
|
|
|
std::unique_ptr<Function> F(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F"));
|
|
|
|
Argument &A = *F->arg_begin();
|
|
|
|
|
|
|
|
auto *LAM = LocalAsMetadata::get(&A);
|
|
|
|
auto *MAV = MetadataAsValue::get(C, LAM);
|
|
|
|
|
|
|
|
// The principled answer to a LocalAsMetadata of an unmapped SSA value would
|
|
|
|
// be to return nullptr (regardless of RF_IgnoreMissingLocals).
|
|
|
|
//
|
|
|
|
// However, algorithms that use RemapInstruction assume that each instruction
|
|
|
|
// only references SSA values from previous instructions. Arguments of
|
|
|
|
// such as "metadata i32 %x" don't currently successfully maintain that
|
|
|
|
// property. To keep RemapInstruction from crashing we need a non-null
|
|
|
|
// return here, but we also shouldn't reference the unmapped local. Use
|
|
|
|
// "metadata !{}".
|
|
|
|
auto *N0 = MDTuple::get(C, None);
|
|
|
|
auto *N0AV = MetadataAsValue::get(C, N0);
|
|
|
|
ValueToValueMapTy VM;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(N0AV, ValueMapper(VM).mapValue(*MAV));
|
|
|
|
EXPECT_EQ(nullptr, ValueMapper(VM, RF_IgnoreMissingLocals).mapValue(*MAV));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
EXPECT_FALSE(VM.count(MAV));
|
|
|
|
EXPECT_FALSE(VM.count(&A));
|
|
|
|
EXPECT_EQ(None, VM.getMappedMD(LAM));
|
|
|
|
|
|
|
|
VM[MAV] = MAV;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(MAV, ValueMapper(VM).mapValue(*MAV));
|
|
|
|
EXPECT_EQ(MAV, ValueMapper(VM, RF_IgnoreMissingLocals).mapValue(*MAV));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
EXPECT_TRUE(VM.count(MAV));
|
|
|
|
EXPECT_FALSE(VM.count(&A));
|
|
|
|
|
|
|
|
VM[MAV] = &A;
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(&A, ValueMapper(VM).mapValue(*MAV));
|
|
|
|
EXPECT_EQ(&A, ValueMapper(VM, RF_IgnoreMissingLocals).mapValue(*MAV));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
EXPECT_TRUE(VM.count(MAV));
|
|
|
|
EXPECT_FALSE(VM.count(&A));
|
|
|
|
}
|
|
|
|
|
2016-04-16 10:29:55 +08:00
|
|
|
TEST(ValueMapperTest, mapValueLocalAsMetadataToConstant) {
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
LLVMContext Context;
|
|
|
|
auto *Int8 = Type::getInt8Ty(Context);
|
|
|
|
FunctionType *FTy = FunctionType::get(Type::getVoidTy(Context), Int8, false);
|
|
|
|
std::unique_ptr<Function> F(
|
|
|
|
Function::Create(FTy, GlobalValue::ExternalLinkage, "F"));
|
|
|
|
|
|
|
|
// Map a local value to a constant.
|
|
|
|
Argument &A = *F->arg_begin();
|
|
|
|
Constant &C = *ConstantInt::get(Int8, 42);
|
|
|
|
ValueToValueMapTy VM;
|
|
|
|
VM[&A] = &C;
|
|
|
|
|
|
|
|
// Look up the metadata-as-value wrapper. Don't crash.
|
|
|
|
auto *MDA = MetadataAsValue::get(Context, ValueAsMetadata::get(&A));
|
|
|
|
auto *MDC = MetadataAsValue::get(Context, ValueAsMetadata::get(&C));
|
|
|
|
EXPECT_TRUE(isa<LocalAsMetadata>(MDA->getMetadata()));
|
|
|
|
EXPECT_TRUE(isa<ConstantAsMetadata>(MDC->getMetadata()));
|
2016-04-16 10:29:55 +08:00
|
|
|
EXPECT_EQ(&C, ValueMapper(VM).mapValue(A));
|
|
|
|
EXPECT_EQ(MDC, ValueMapper(VM).mapValue(*MDA));
|
Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
2016-04-08 11:13:22 +08:00
|
|
|
}
|
|
|
|
|
2016-04-03 00:45:51 +08:00
|
|
|
} // end namespace
|