2007-04-22 14:24:45 +08:00
|
|
|
//===-- ValueEnumerator.cpp - Number values and types for bitcode writer --===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-04-22 14:24:45 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the ValueEnumerator class.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "ValueEnumerator.h"
|
2011-04-07 00:49:37 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2015-02-03 02:53:21 +08:00
|
|
|
#include "llvm/IR/DebugInfoMetadata.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2014-07-26 00:13:16 +08:00
|
|
|
#include "llvm/IR/UseListOrder.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/ValueSymbolTable.h"
|
2011-12-08 04:44:46 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2007-05-04 13:05:48 +08:00
|
|
|
#include <algorithm>
|
2007-04-22 14:24:45 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-07-29 05:19:41 +08:00
|
|
|
namespace {
|
2014-07-30 07:03:40 +08:00
|
|
|
struct OrderMap {
|
|
|
|
DenseMap<const Value *, std::pair<unsigned, bool>> IDs;
|
2014-07-30 09:22:16 +08:00
|
|
|
unsigned LastGlobalConstantID;
|
|
|
|
unsigned LastGlobalValueID;
|
|
|
|
|
|
|
|
OrderMap() : LastGlobalConstantID(0), LastGlobalValueID(0) {}
|
|
|
|
|
|
|
|
bool isGlobalConstant(unsigned ID) const {
|
|
|
|
return ID <= LastGlobalConstantID;
|
|
|
|
}
|
|
|
|
bool isGlobalValue(unsigned ID) const {
|
|
|
|
return ID <= LastGlobalValueID && !isGlobalConstant(ID);
|
|
|
|
}
|
2014-07-30 07:03:40 +08:00
|
|
|
|
|
|
|
unsigned size() const { return IDs.size(); }
|
|
|
|
std::pair<unsigned, bool> &operator[](const Value *V) { return IDs[V]; }
|
|
|
|
std::pair<unsigned, bool> lookup(const Value *V) const {
|
|
|
|
return IDs.lookup(V);
|
|
|
|
}
|
2014-07-30 09:20:26 +08:00
|
|
|
void index(const Value *V) {
|
|
|
|
// Explicitly sequence get-size and insert-value operations to avoid UB.
|
|
|
|
unsigned ID = IDs.size() + 1;
|
|
|
|
IDs[V].first = ID;
|
|
|
|
}
|
2014-07-30 07:03:40 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2014-07-29 05:19:41 +08:00
|
|
|
|
|
|
|
static void orderValue(const Value *V, OrderMap &OM) {
|
|
|
|
if (OM.lookup(V).first)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (const Constant *C = dyn_cast<Constant>(V))
|
|
|
|
if (C->getNumOperands() && !isa<GlobalValue>(C))
|
|
|
|
for (const Value *Op : C->operands())
|
2014-07-30 09:22:16 +08:00
|
|
|
if (!isa<BasicBlock>(Op) && !isa<GlobalValue>(Op))
|
2014-07-29 05:19:41 +08:00
|
|
|
orderValue(Op, OM);
|
|
|
|
|
|
|
|
// Note: we cannot cache this lookup above, since inserting into the map
|
2014-07-30 09:20:26 +08:00
|
|
|
// changes the map's size, and thus affects the other IDs.
|
|
|
|
OM.index(V);
|
2014-07-29 05:19:41 +08:00
|
|
|
}
|
|
|
|
|
2014-11-18 04:06:27 +08:00
|
|
|
static OrderMap orderModule(const Module &M) {
|
2014-07-29 05:19:41 +08:00
|
|
|
// This needs to match the order used by ValueEnumerator::ValueEnumerator()
|
|
|
|
// and ValueEnumerator::incorporateFunction().
|
|
|
|
OrderMap OM;
|
|
|
|
|
2014-07-30 09:22:16 +08:00
|
|
|
// In the reader, initializers of GlobalValues are set *after* all the
|
|
|
|
// globals have been read. Rather than awkwardly modeling this behaviour
|
|
|
|
// directly in predictValueUseListOrderImpl(), just assign IDs to
|
|
|
|
// initializers of GlobalValues before GlobalValues themselves to model this
|
|
|
|
// implicitly.
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalVariable &G : M.globals())
|
2014-07-29 05:19:41 +08:00
|
|
|
if (G.hasInitializer())
|
2014-07-31 08:13:28 +08:00
|
|
|
if (!isa<GlobalValue>(G.getInitializer()))
|
|
|
|
orderValue(G.getInitializer(), OM);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalAlias &A : M.aliases())
|
2014-07-31 08:13:28 +08:00
|
|
|
if (!isa<GlobalValue>(A.getAliasee()))
|
|
|
|
orderValue(A.getAliasee(), OM);
|
2016-04-07 20:32:19 +08:00
|
|
|
for (const GlobalIFunc &I : M.ifuncs())
|
|
|
|
if (!isa<GlobalValue>(I.getResolver()))
|
|
|
|
orderValue(I.getResolver(), OM);
|
2014-12-03 10:08:38 +08:00
|
|
|
for (const Function &F : M) {
|
2015-12-19 16:52:49 +08:00
|
|
|
for (const Use &U : F.operands())
|
|
|
|
if (!isa<GlobalValue>(U.get()))
|
|
|
|
orderValue(U.get(), OM);
|
2014-12-03 10:08:38 +08:00
|
|
|
}
|
2014-07-30 09:22:16 +08:00
|
|
|
OM.LastGlobalConstantID = OM.size();
|
|
|
|
|
|
|
|
// Initializers of GlobalValues are processed in
|
|
|
|
// BitcodeReader::ResolveGlobalAndAliasInits(). Match the order there rather
|
|
|
|
// than ValueEnumerator, and match the code in predictValueUseListOrderImpl()
|
|
|
|
// by giving IDs in reverse order.
|
|
|
|
//
|
|
|
|
// Since GlobalValues never reference each other directly (just through
|
|
|
|
// initializers), their relative IDs only matter for determining order of
|
|
|
|
// uses in their initializers.
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const Function &F : M)
|
2014-07-30 09:22:16 +08:00
|
|
|
orderValue(&F, OM);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalAlias &A : M.aliases())
|
2014-07-30 09:22:16 +08:00
|
|
|
orderValue(&A, OM);
|
2016-04-07 20:32:19 +08:00
|
|
|
for (const GlobalIFunc &I : M.ifuncs())
|
|
|
|
orderValue(&I, OM);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalVariable &G : M.globals())
|
2014-07-30 09:22:16 +08:00
|
|
|
orderValue(&G, OM);
|
|
|
|
OM.LastGlobalValueID = OM.size();
|
2014-07-29 05:19:41 +08:00
|
|
|
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const Function &F : M) {
|
2014-07-29 05:19:41 +08:00
|
|
|
if (F.isDeclaration())
|
|
|
|
continue;
|
|
|
|
// Here we need to match the union of ValueEnumerator::incorporateFunction()
|
|
|
|
// and WriteFunction(). Basic blocks are implicitly declared before
|
|
|
|
// anything else (by declaring their size).
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
orderValue(&BB, OM);
|
|
|
|
for (const Argument &A : F.args())
|
|
|
|
orderValue(&A, OM);
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
for (const Instruction &I : BB)
|
|
|
|
for (const Value *Op : I.operands())
|
|
|
|
if ((isa<Constant>(*Op) && !isa<GlobalValue>(*Op)) ||
|
|
|
|
isa<InlineAsm>(*Op))
|
|
|
|
orderValue(Op, OM);
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
for (const Instruction &I : BB)
|
|
|
|
orderValue(&I, OM);
|
|
|
|
}
|
|
|
|
return OM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void predictValueUseListOrderImpl(const Value *V, const Function *F,
|
|
|
|
unsigned ID, const OrderMap &OM,
|
|
|
|
UseListOrderStack &Stack) {
|
|
|
|
// Predict use-list order for this one.
|
|
|
|
typedef std::pair<const Use *, unsigned> Entry;
|
|
|
|
SmallVector<Entry, 64> List;
|
|
|
|
for (const Use &U : V->uses())
|
|
|
|
// Check if this user will be serialized.
|
|
|
|
if (OM.lookup(U.getUser()).first)
|
|
|
|
List.push_back(std::make_pair(&U, List.size()));
|
|
|
|
|
|
|
|
if (List.size() < 2)
|
|
|
|
// We may have lost some users.
|
|
|
|
return;
|
|
|
|
|
2014-07-30 09:22:16 +08:00
|
|
|
bool IsGlobalValue = OM.isGlobalValue(ID);
|
|
|
|
std::sort(List.begin(), List.end(), [&](const Entry &L, const Entry &R) {
|
2014-07-29 05:19:41 +08:00
|
|
|
const Use *LU = L.first;
|
|
|
|
const Use *RU = R.first;
|
2014-07-29 09:13:56 +08:00
|
|
|
if (LU == RU)
|
|
|
|
return false;
|
|
|
|
|
2014-07-29 05:19:41 +08:00
|
|
|
auto LID = OM.lookup(LU->getUser()).first;
|
|
|
|
auto RID = OM.lookup(RU->getUser()).first;
|
2014-07-30 09:22:16 +08:00
|
|
|
|
|
|
|
// Global values are processed in reverse order.
|
|
|
|
//
|
|
|
|
// Moreover, initializers of GlobalValues are set *after* all the globals
|
|
|
|
// have been read (despite having earlier IDs). Rather than awkwardly
|
|
|
|
// modeling this behaviour here, orderModule() has assigned IDs to
|
|
|
|
// initializers of GlobalValues before GlobalValues themselves.
|
|
|
|
if (OM.isGlobalValue(LID) && OM.isGlobalValue(RID))
|
|
|
|
return LID < RID;
|
|
|
|
|
2014-07-29 05:19:41 +08:00
|
|
|
// If ID is 4, then expect: 7 6 5 1 2 3.
|
|
|
|
if (LID < RID) {
|
2014-08-01 02:33:12 +08:00
|
|
|
if (RID <= ID)
|
2014-07-30 09:22:16 +08:00
|
|
|
if (!IsGlobalValue) // GlobalValue uses don't get reversed.
|
|
|
|
return true;
|
2014-07-29 05:19:41 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (RID < LID) {
|
2014-08-01 02:33:12 +08:00
|
|
|
if (LID <= ID)
|
2014-07-30 09:22:16 +08:00
|
|
|
if (!IsGlobalValue) // GlobalValue uses don't get reversed.
|
|
|
|
return false;
|
2014-07-29 05:19:41 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-07-30 09:22:16 +08:00
|
|
|
|
2014-07-29 05:19:41 +08:00
|
|
|
// LID and RID are equal, so we have different operands of the same user.
|
|
|
|
// Assume operands are added in order for all instructions.
|
2014-08-01 02:33:12 +08:00
|
|
|
if (LID <= ID)
|
2014-07-30 09:22:16 +08:00
|
|
|
if (!IsGlobalValue) // GlobalValue uses don't get reversed.
|
|
|
|
return LU->getOperandNo() < RU->getOperandNo();
|
|
|
|
return LU->getOperandNo() > RU->getOperandNo();
|
2014-07-29 05:19:41 +08:00
|
|
|
});
|
|
|
|
|
|
|
|
if (std::is_sorted(
|
|
|
|
List.begin(), List.end(),
|
|
|
|
[](const Entry &L, const Entry &R) { return L.second < R.second; }))
|
|
|
|
// Order is already correct.
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Store the shuffle.
|
2014-07-30 00:58:18 +08:00
|
|
|
Stack.emplace_back(V, F, List.size());
|
|
|
|
assert(List.size() == Stack.back().Shuffle.size() && "Wrong size");
|
2014-07-29 06:41:50 +08:00
|
|
|
for (size_t I = 0, E = List.size(); I != E; ++I)
|
2014-07-30 00:58:18 +08:00
|
|
|
Stack.back().Shuffle[I] = List[I].second;
|
2014-07-29 05:19:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void predictValueUseListOrder(const Value *V, const Function *F,
|
|
|
|
OrderMap &OM, UseListOrderStack &Stack) {
|
|
|
|
auto &IDPair = OM[V];
|
|
|
|
assert(IDPair.first && "Unmapped value");
|
|
|
|
if (IDPair.second)
|
|
|
|
// Already predicted.
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Do the actual prediction.
|
|
|
|
IDPair.second = true;
|
|
|
|
if (!V->use_empty() && std::next(V->use_begin()) != V->use_end())
|
|
|
|
predictValueUseListOrderImpl(V, F, IDPair.first, OM, Stack);
|
|
|
|
|
|
|
|
// Recursive descent into constants.
|
|
|
|
if (const Constant *C = dyn_cast<Constant>(V))
|
2014-07-31 01:51:09 +08:00
|
|
|
if (C->getNumOperands()) // Visit GlobalValues.
|
2014-07-29 05:19:41 +08:00
|
|
|
for (const Value *Op : C->operands())
|
2014-07-31 01:51:09 +08:00
|
|
|
if (isa<Constant>(Op)) // Visit GlobalValues.
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(Op, F, OM, Stack);
|
|
|
|
}
|
|
|
|
|
2014-11-18 04:06:27 +08:00
|
|
|
static UseListOrderStack predictUseListOrder(const Module &M) {
|
2014-07-29 05:19:41 +08:00
|
|
|
OrderMap OM = orderModule(M);
|
|
|
|
|
|
|
|
// Use-list orders need to be serialized after all the users have been added
|
|
|
|
// to a value, or else the shuffles will be incomplete. Store them per
|
|
|
|
// function in a stack.
|
|
|
|
//
|
|
|
|
// Aside from function order, the order of values doesn't matter much here.
|
|
|
|
UseListOrderStack Stack;
|
|
|
|
|
|
|
|
// We want to visit the functions backward now so we can list function-local
|
|
|
|
// constants in the last Function they're used in. Module-level constants
|
|
|
|
// have already been visited above.
|
2014-11-18 04:06:27 +08:00
|
|
|
for (auto I = M.rbegin(), E = M.rend(); I != E; ++I) {
|
2014-07-29 05:19:41 +08:00
|
|
|
const Function &F = *I;
|
|
|
|
if (F.isDeclaration())
|
|
|
|
continue;
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
predictValueUseListOrder(&BB, &F, OM, Stack);
|
|
|
|
for (const Argument &A : F.args())
|
|
|
|
predictValueUseListOrder(&A, &F, OM, Stack);
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
for (const Instruction &I : BB)
|
|
|
|
for (const Value *Op : I.operands())
|
2014-07-31 01:51:09 +08:00
|
|
|
if (isa<Constant>(*Op) || isa<InlineAsm>(*Op)) // Visit GlobalValues.
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(Op, &F, OM, Stack);
|
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
for (const Instruction &I : BB)
|
|
|
|
predictValueUseListOrder(&I, &F, OM, Stack);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Visit globals last, since the module-level use-list block will be seen
|
|
|
|
// before the function bodies are processed.
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalVariable &G : M.globals())
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(&G, nullptr, OM, Stack);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const Function &F : M)
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(&F, nullptr, OM, Stack);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalAlias &A : M.aliases())
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(&A, nullptr, OM, Stack);
|
2016-04-07 20:32:19 +08:00
|
|
|
for (const GlobalIFunc &I : M.ifuncs())
|
|
|
|
predictValueUseListOrder(&I, nullptr, OM, Stack);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalVariable &G : M.globals())
|
2014-07-29 05:19:41 +08:00
|
|
|
if (G.hasInitializer())
|
|
|
|
predictValueUseListOrder(G.getInitializer(), nullptr, OM, Stack);
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const GlobalAlias &A : M.aliases())
|
2014-07-29 05:19:41 +08:00
|
|
|
predictValueUseListOrder(A.getAliasee(), nullptr, OM, Stack);
|
2016-04-07 20:32:19 +08:00
|
|
|
for (const GlobalIFunc &I : M.ifuncs())
|
|
|
|
predictValueUseListOrder(I.getResolver(), nullptr, OM, Stack);
|
2014-12-03 10:08:38 +08:00
|
|
|
for (const Function &F : M) {
|
2015-12-19 16:52:49 +08:00
|
|
|
for (const Use &U : F.operands())
|
|
|
|
predictValueUseListOrder(U.get(), nullptr, OM, Stack);
|
2014-12-03 10:08:38 +08:00
|
|
|
}
|
2014-07-29 05:19:41 +08:00
|
|
|
|
|
|
|
return Stack;
|
|
|
|
}
|
|
|
|
|
2012-11-13 20:59:33 +08:00
|
|
|
static bool isIntOrIntVectorValue(const std::pair<const Value*, unsigned> &V) {
|
|
|
|
return V.first->getType()->isIntOrIntVectorTy();
|
2007-05-04 13:21:47 +08:00
|
|
|
}
|
|
|
|
|
2015-04-15 07:45:11 +08:00
|
|
|
ValueEnumerator::ValueEnumerator(const Module &M,
|
|
|
|
bool ShouldPreserveUseListOrder)
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
: ShouldPreserveUseListOrder(ShouldPreserveUseListOrder) {
|
2015-04-15 07:45:11 +08:00
|
|
|
if (ShouldPreserveUseListOrder)
|
2014-07-29 05:19:41 +08:00
|
|
|
UseListOrders = predictUseListOrder(M);
|
|
|
|
|
2007-04-22 14:24:45 +08:00
|
|
|
// Enumerate the global variables.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const GlobalVariable &GV : M.globals())
|
|
|
|
EnumerateValue(&GV);
|
2007-04-22 14:24:45 +08:00
|
|
|
|
|
|
|
// Enumerate the functions.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const Function & F : M) {
|
|
|
|
EnumerateValue(&F);
|
|
|
|
EnumerateAttributes(F.getAttributes());
|
2007-11-27 21:23:08 +08:00
|
|
|
}
|
2007-04-22 14:24:45 +08:00
|
|
|
|
2007-04-26 10:46:40 +08:00
|
|
|
// Enumerate the aliases.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const GlobalAlias &GA : M.aliases())
|
|
|
|
EnumerateValue(&GA);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2016-04-07 20:32:19 +08:00
|
|
|
// Enumerate the ifuncs.
|
|
|
|
for (const GlobalIFunc &GIF : M.ifuncs())
|
|
|
|
EnumerateValue(&GIF);
|
|
|
|
|
2007-05-04 13:21:47 +08:00
|
|
|
// Remember what is the cutoff between globalvalue's and other constants.
|
|
|
|
unsigned FirstConstant = Values.size();
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-04-22 14:24:45 +08:00
|
|
|
// Enumerate the global variable initializers.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const GlobalVariable &GV : M.globals())
|
|
|
|
if (GV.hasInitializer())
|
|
|
|
EnumerateValue(GV.getInitializer());
|
2007-04-22 14:24:45 +08:00
|
|
|
|
2007-04-26 10:46:40 +08:00
|
|
|
// Enumerate the aliasees.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const GlobalAlias &GA : M.aliases())
|
|
|
|
EnumerateValue(GA.getAliasee());
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2016-04-07 20:32:19 +08:00
|
|
|
// Enumerate the ifunc resolvers.
|
|
|
|
for (const GlobalIFunc &GIF : M.ifuncs())
|
|
|
|
EnumerateValue(GIF.getResolver());
|
|
|
|
|
2015-12-19 16:52:49 +08:00
|
|
|
// Enumerate any optional Function data.
|
2015-06-13 04:18:20 +08:00
|
|
|
for (const Function &F : M)
|
2015-12-19 16:52:49 +08:00
|
|
|
for (const Use &U : F.operands())
|
|
|
|
EnumerateValue(U.get());
|
2015-06-18 04:52:32 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
// Enumerate the metadata type.
|
|
|
|
//
|
|
|
|
// TODO: Move this to ValueEnumerator::EnumerateOperandType() once bitcode
|
|
|
|
// only encodes the metadata type when it's used as a value.
|
|
|
|
EnumerateType(Type::getMetadataTy(M.getContext()));
|
|
|
|
|
2013-04-01 10:28:07 +08:00
|
|
|
// Insert constants and metadata that are named at module level into the slot
|
2010-01-08 03:39:36 +08:00
|
|
|
// pool so that the module symbol table can refer to them...
|
2014-11-18 04:06:27 +08:00
|
|
|
EnumerateValueSymbolTable(M.getValueSymbolTable());
|
2010-07-22 07:38:33 +08:00
|
|
|
EnumerateNamedMetadata(M);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2014-11-12 05:30:22 +08:00
|
|
|
SmallVector<std::pair<unsigned, MDNode *>, 8> MDs;
|
2016-06-01 07:01:54 +08:00
|
|
|
for (const GlobalVariable &GV : M.globals()) {
|
2016-06-01 09:17:57 +08:00
|
|
|
MDs.clear();
|
2016-06-01 07:01:54 +08:00
|
|
|
GV.getAllMetadata(MDs);
|
|
|
|
for (const auto &I : MDs)
|
2016-06-22 07:42:48 +08:00
|
|
|
// FIXME: Pass GV to EnumerateMetadata and arrange for the bitcode writer
|
|
|
|
// to write metadata to the global variable's own metadata block
|
|
|
|
// (PR28134).
|
|
|
|
EnumerateMetadata(nullptr, I.second);
|
2016-06-01 07:01:54 +08:00
|
|
|
}
|
2009-12-31 08:51:46 +08:00
|
|
|
|
2007-04-26 11:50:57 +08:00
|
|
|
// Enumerate types used by function bodies and argument lists.
|
2014-11-18 04:06:27 +08:00
|
|
|
for (const Function &F : M) {
|
2014-06-17 11:00:40 +08:00
|
|
|
for (const Argument &A : F.args())
|
|
|
|
EnumerateType(A.getType());
|
|
|
|
|
2015-04-25 06:04:41 +08:00
|
|
|
// Enumerate metadata attached to this function.
|
2016-06-01 09:17:57 +08:00
|
|
|
MDs.clear();
|
2015-04-25 06:04:41 +08:00
|
|
|
F.getAllMetadata(MDs);
|
|
|
|
for (const auto &I : MDs)
|
2016-06-22 07:42:48 +08:00
|
|
|
EnumerateMetadata(F.isDeclaration() ? nullptr : &F, I.second);
|
2015-04-25 06:04:41 +08:00
|
|
|
|
2014-06-17 11:00:40 +08:00
|
|
|
for (const BasicBlock &BB : F)
|
|
|
|
for (const Instruction &I : BB) {
|
|
|
|
for (const Use &Op : I.operands()) {
|
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-10 02:38:53 +08:00
|
|
|
auto *MD = dyn_cast<MetadataAsValue>(&Op);
|
|
|
|
if (!MD) {
|
|
|
|
EnumerateOperandType(Op);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Local metadata is enumerated during function-incorporation.
|
|
|
|
if (isa<LocalAsMetadata>(MD->getMetadata()))
|
|
|
|
continue;
|
|
|
|
|
2016-04-02 23:22:57 +08:00
|
|
|
EnumerateMetadata(&F, MD->getMetadata());
|
2010-01-15 03:54:11 +08:00
|
|
|
}
|
2014-06-17 11:00:40 +08:00
|
|
|
EnumerateType(I.getType());
|
|
|
|
if (const CallInst *CI = dyn_cast<CallInst>(&I))
|
2008-09-26 05:00:45 +08:00
|
|
|
EnumerateAttributes(CI->getAttributes());
|
2014-06-17 11:00:40 +08:00
|
|
|
else if (const InvokeInst *II = dyn_cast<InvokeInst>(&I))
|
2008-09-26 05:00:45 +08:00
|
|
|
EnumerateAttributes(II->getAttributes());
|
2009-09-19 03:26:43 +08:00
|
|
|
|
2009-09-20 10:20:51 +08:00
|
|
|
// Enumerate metadata attached with this instruction.
|
2009-10-23 02:55:16 +08:00
|
|
|
MDs.clear();
|
2014-06-17 11:00:40 +08:00
|
|
|
I.getAllMetadataOtherThanDebugLoc(MDs);
|
2009-12-29 07:41:32 +08:00
|
|
|
for (unsigned i = 0, e = MDs.size(); i != e; ++i)
|
2016-04-02 23:22:57 +08:00
|
|
|
EnumerateMetadata(&F, MDs[i].second);
|
2012-11-25 23:23:39 +08:00
|
|
|
|
2015-03-31 03:40:05 +08:00
|
|
|
// Don't enumerate the location directly -- it has a special record
|
|
|
|
// type -- but enumerate its operands.
|
2015-04-30 00:38:44 +08:00
|
|
|
if (DILocation *L = I.getDebugLoc())
|
2016-04-19 11:46:51 +08:00
|
|
|
for (const Metadata *Op : L->operands())
|
|
|
|
EnumerateMetadata(&F, Op);
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
|
|
|
}
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-05-04 13:21:47 +08:00
|
|
|
// Optimize constant ordering.
|
|
|
|
OptimizeConstants(FirstConstant, Values.size());
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
|
|
|
|
// Organize metadata ordering.
|
|
|
|
organizeMetadata();
|
2011-04-07 00:49:37 +08:00
|
|
|
}
|
|
|
|
|
2009-09-19 03:26:43 +08:00
|
|
|
unsigned ValueEnumerator::getInstructionID(const Instruction *Inst) const {
|
|
|
|
InstructionMapType::const_iterator I = InstructionMap.find(Inst);
|
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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
assert(I != InstructionMap.end() && "Instruction is not mapped!");
|
2010-08-26 01:09:50 +08:00
|
|
|
return I->second;
|
2009-09-20 10:20:51 +08:00
|
|
|
}
|
2009-09-19 03:26:43 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
unsigned ValueEnumerator::getComdatID(const Comdat *C) const {
|
|
|
|
unsigned ComdatID = Comdats.idFor(C);
|
|
|
|
assert(ComdatID && "Comdat not found!");
|
|
|
|
return ComdatID;
|
|
|
|
}
|
|
|
|
|
2009-09-19 03:26:43 +08:00
|
|
|
void ValueEnumerator::setInstructionID(const Instruction *I) {
|
|
|
|
InstructionMap[I] = InstructionCount++;
|
|
|
|
}
|
|
|
|
|
2009-08-04 14:00:18 +08:00
|
|
|
unsigned ValueEnumerator::getValueID(const Value *V) const {
|
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-10 02:38:53 +08:00
|
|
|
if (auto *MD = dyn_cast<MetadataAsValue>(V))
|
|
|
|
return getMetadataID(MD->getMetadata());
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2009-08-04 14:00:18 +08:00
|
|
|
ValueMapType::const_iterator I = ValueMap.find(V);
|
|
|
|
assert(I != ValueMap.end() && "Value not in slotcalculator!");
|
|
|
|
return I->second-1;
|
|
|
|
}
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2016-01-30 04:50:44 +08:00
|
|
|
LLVM_DUMP_METHOD void ValueEnumerator::dump() const {
|
2011-12-08 04:44:46 +08:00
|
|
|
print(dbgs(), ValueMap, "Default");
|
|
|
|
dbgs() << '\n';
|
2015-12-30 07:00:22 +08:00
|
|
|
print(dbgs(), MetadataMap, "MetaData");
|
2011-12-08 04:44:46 +08:00
|
|
|
dbgs() << '\n';
|
|
|
|
}
|
|
|
|
|
|
|
|
void ValueEnumerator::print(raw_ostream &OS, const ValueMapType &Map,
|
|
|
|
const char *Name) const {
|
|
|
|
|
|
|
|
OS << "Map Name: " << Name << "\n";
|
|
|
|
OS << "Size: " << Map.size() << "\n";
|
|
|
|
for (ValueMapType::const_iterator I = Map.begin(),
|
|
|
|
E = Map.end(); I != E; ++I) {
|
|
|
|
|
|
|
|
const Value *V = I->first;
|
|
|
|
if (V->hasName())
|
|
|
|
OS << "Value: " << V->getName();
|
|
|
|
else
|
|
|
|
OS << "Value: [null]\n";
|
|
|
|
V->dump();
|
|
|
|
|
|
|
|
OS << " Uses(" << std::distance(V->use_begin(),V->use_end()) << "):";
|
2014-03-09 11:16:01 +08:00
|
|
|
for (const Use &U : V->uses()) {
|
|
|
|
if (&U != &*V->use_begin())
|
2011-12-08 04:44:46 +08:00
|
|
|
OS << ",";
|
2014-03-09 11:16:01 +08:00
|
|
|
if(U->hasName())
|
|
|
|
OS << " " << U->getName();
|
2011-12-08 04:44:46 +08:00
|
|
|
else
|
|
|
|
OS << " [null]";
|
|
|
|
|
|
|
|
}
|
|
|
|
OS << "\n\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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
void ValueEnumerator::print(raw_ostream &OS, const MetadataMapType &Map,
|
|
|
|
const char *Name) const {
|
|
|
|
|
|
|
|
OS << "Map Name: " << Name << "\n";
|
|
|
|
OS << "Size: " << Map.size() << "\n";
|
|
|
|
for (auto I = Map.begin(), E = Map.end(); I != E; ++I) {
|
|
|
|
const Metadata *MD = I->first;
|
2016-04-02 23:22:57 +08:00
|
|
|
OS << "Metadata: slot = " << I->second.ID << "\n";
|
|
|
|
OS << "Metadata: function = " << I->second.F << "\n";
|
2014-12-17 09:52:08 +08:00
|
|
|
MD->print(OS);
|
2016-04-02 23:22:57 +08:00
|
|
|
OS << "\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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-04 13:21:47 +08:00
|
|
|
/// OptimizeConstants - Reorder constant pool for denser encoding.
|
|
|
|
void ValueEnumerator::OptimizeConstants(unsigned CstStart, unsigned CstEnd) {
|
|
|
|
if (CstStart == CstEnd || CstStart+1 == CstEnd) return;
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2015-04-15 07:45:11 +08:00
|
|
|
if (ShouldPreserveUseListOrder)
|
2014-07-26 00:13:16 +08:00
|
|
|
// Optimizing constants makes the use-list order difficult to predict.
|
|
|
|
// Disable it for now when trying to preserve the order.
|
|
|
|
return;
|
|
|
|
|
2014-03-01 19:47:00 +08:00
|
|
|
std::stable_sort(Values.begin() + CstStart, Values.begin() + CstEnd,
|
|
|
|
[this](const std::pair<const Value *, unsigned> &LHS,
|
|
|
|
const std::pair<const Value *, unsigned> &RHS) {
|
|
|
|
// Sort by plane.
|
|
|
|
if (LHS.first->getType() != RHS.first->getType())
|
|
|
|
return getTypeID(LHS.first->getType()) < getTypeID(RHS.first->getType());
|
|
|
|
// Then by frequency.
|
|
|
|
return LHS.second > RHS.second;
|
|
|
|
});
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2012-11-13 20:59:33 +08:00
|
|
|
// Ensure that integer and vector of integer constants are at the start of the
|
|
|
|
// constant pool. This is important so that GEP structure indices come before
|
|
|
|
// gep constant exprs.
|
2016-03-25 10:20:28 +08:00
|
|
|
std::stable_partition(Values.begin() + CstStart, Values.begin() + CstEnd,
|
|
|
|
isIntOrIntVectorValue);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-05-04 13:21:47 +08:00
|
|
|
// Rebuild the modified portion of ValueMap.
|
|
|
|
for (; CstStart != CstEnd; ++CstStart)
|
|
|
|
ValueMap[Values[CstStart].first] = CstStart+1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-04-22 14:24:45 +08:00
|
|
|
/// EnumerateValueSymbolTable - Insert all of the values in the specified symbol
|
|
|
|
/// table into the values table.
|
|
|
|
void ValueEnumerator::EnumerateValueSymbolTable(const ValueSymbolTable &VST) {
|
2009-09-20 10:20:51 +08:00
|
|
|
for (ValueSymbolTable::const_iterator VI = VST.begin(), VE = VST.end();
|
2007-04-22 14:24:45 +08:00
|
|
|
VI != VE; ++VI)
|
|
|
|
EnumerateValue(VI->getValue());
|
|
|
|
}
|
|
|
|
|
2014-11-18 04:06:27 +08:00
|
|
|
/// Insert all of the values referenced by named metadata in the specified
|
|
|
|
/// module.
|
|
|
|
void ValueEnumerator::EnumerateNamedMetadata(const Module &M) {
|
2015-10-13 11:26:19 +08:00
|
|
|
for (const auto &I : M.named_metadata())
|
|
|
|
EnumerateNamedMDNode(&I);
|
2010-01-08 03:39:36 +08:00
|
|
|
}
|
|
|
|
|
2010-01-09 08:30:14 +08:00
|
|
|
void ValueEnumerator::EnumerateNamedMDNode(const NamedMDNode *MD) {
|
|
|
|
for (unsigned i = 0, e = MD->getNumOperands(); i != e; ++i)
|
2016-04-02 23:22:57 +08:00
|
|
|
EnumerateMetadata(nullptr, MD->getOperand(i));
|
|
|
|
}
|
|
|
|
|
2016-06-22 07:42:48 +08:00
|
|
|
unsigned ValueEnumerator::getMetadataFunctionID(const Function *F) const {
|
|
|
|
return F ? getValueID(F) + 1 : 0;
|
2016-04-02 23:22:57 +08:00
|
|
|
}
|
|
|
|
|
2016-06-22 07:42:48 +08:00
|
|
|
void ValueEnumerator::EnumerateMetadata(const Function *F, const Metadata *MD) {
|
|
|
|
EnumerateMetadata(getMetadataFunctionID(F), MD);
|
2016-04-02 23:22:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ValueEnumerator::EnumerateFunctionLocalMetadata(
|
|
|
|
const Function &F, const LocalAsMetadata *Local) {
|
2016-06-22 07:42:48 +08:00
|
|
|
EnumerateFunctionLocalMetadata(getMetadataFunctionID(&F), Local);
|
2010-01-09 08:30:14 +08:00
|
|
|
}
|
|
|
|
|
2016-04-19 11:46:51 +08:00
|
|
|
void ValueEnumerator::dropFunctionFromMetadata(
|
|
|
|
MetadataMapType::value_type &FirstMD) {
|
2016-04-18 09:24:58 +08:00
|
|
|
SmallVector<const MDNode *, 64> Worklist;
|
2016-04-19 11:46:51 +08:00
|
|
|
auto push = [this, &Worklist](MetadataMapType::value_type &MD) {
|
|
|
|
auto &Entry = MD.second;
|
|
|
|
|
|
|
|
// Nothing to do if this metadata isn't tagged.
|
|
|
|
if (!Entry.F)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Drop the function tag.
|
|
|
|
Entry.F = 0;
|
|
|
|
|
|
|
|
// If this is has an ID and is an MDNode, then its operands have entries as
|
|
|
|
// well. We need to drop the function from them too.
|
|
|
|
if (Entry.ID)
|
|
|
|
if (auto *N = dyn_cast<MDNode>(MD.first))
|
|
|
|
Worklist.push_back(N);
|
|
|
|
};
|
|
|
|
push(FirstMD);
|
|
|
|
while (!Worklist.empty())
|
2016-04-18 09:24:58 +08:00
|
|
|
for (const Metadata *Op : Worklist.pop_back_val()->operands()) {
|
2016-04-02 23:22:57 +08:00
|
|
|
if (!Op)
|
|
|
|
continue;
|
2016-04-19 11:46:51 +08:00
|
|
|
auto MD = MetadataMap.find(Op);
|
|
|
|
if (MD != MetadataMap.end())
|
|
|
|
push(*MD);
|
|
|
|
}
|
|
|
|
}
|
2016-04-02 23:22:57 +08:00
|
|
|
|
2016-04-19 11:46:51 +08:00
|
|
|
void ValueEnumerator::EnumerateMetadata(unsigned F, const Metadata *MD) {
|
BitcodeWriter: Emit uniqued subgraphs after all distinct nodes
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.
Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references. In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled. This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).
Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves. Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).
I've added two testcases:
- test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
instead of uniqued ones. This confirms that, in the absence of
uniqued nodes, distinct nodes are still emitted in post-order.
- test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
example where a naive post-order traversal would cause one uniqued
node to forward-reference another. IOW, it's the motivating test.
llvm-svn: 267278
2016-04-23 12:59:22 +08:00
|
|
|
// It's vital for reader efficiency that uniqued subgraphs are done in
|
|
|
|
// post-order; it's expensive when their operands have forward references.
|
|
|
|
// If a distinct node is referenced from a uniqued node, it'll be delayed
|
|
|
|
// until the uniqued subgraph has been completely traversed.
|
|
|
|
SmallVector<const MDNode *, 32> DelayedDistinctNodes;
|
|
|
|
|
2016-04-19 11:46:51 +08:00
|
|
|
// Start by enumerating MD, and then work through its transitive operands in
|
2016-04-21 09:55:12 +08:00
|
|
|
// post-order. This requires a depth-first search.
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
SmallVector<std::pair<const MDNode *, MDNode::op_iterator>, 32> Worklist;
|
|
|
|
if (const MDNode *N = enumerateMetadataImpl(F, MD))
|
|
|
|
Worklist.push_back(std::make_pair(N, N->op_begin()));
|
|
|
|
|
2016-04-19 11:46:51 +08:00
|
|
|
while (!Worklist.empty()) {
|
|
|
|
const MDNode *N = Worklist.back().first;
|
2016-04-21 09:55:12 +08:00
|
|
|
|
2016-04-23 12:22:38 +08:00
|
|
|
// Enumerate operands until we hit a new node. We need to traverse these
|
|
|
|
// nodes' operands before visiting the rest of N's operands.
|
|
|
|
MDNode::op_iterator I = std::find_if(
|
|
|
|
Worklist.back().second, N->op_end(),
|
|
|
|
[&](const Metadata *MD) { return enumerateMetadataImpl(F, MD); });
|
|
|
|
if (I != N->op_end()) {
|
|
|
|
auto *Op = cast<MDNode>(*I);
|
|
|
|
Worklist.back().second = ++I;
|
BitcodeWriter: Emit uniqued subgraphs after all distinct nodes
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.
Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references. In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled. This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).
Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves. Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).
I've added two testcases:
- test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
instead of uniqued ones. This confirms that, in the absence of
uniqued nodes, distinct nodes are still emitted in post-order.
- test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
example where a naive post-order traversal would cause one uniqued
node to forward-reference another. IOW, it's the motivating test.
llvm-svn: 267278
2016-04-23 12:59:22 +08:00
|
|
|
|
|
|
|
// Delay traversing Op if it's a distinct node and N is uniqued.
|
|
|
|
if (Op->isDistinct() && !N->isDistinct())
|
|
|
|
DelayedDistinctNodes.push_back(Op);
|
|
|
|
else
|
|
|
|
Worklist.push_back(std::make_pair(Op, Op->op_begin()));
|
2016-04-19 11:46:51 +08:00
|
|
|
continue;
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
}
|
2016-04-19 11:46:51 +08:00
|
|
|
|
|
|
|
// All the operands have been visited. Now assign an ID.
|
|
|
|
Worklist.pop_back();
|
|
|
|
MDs.push_back(N);
|
|
|
|
MetadataMap[N].ID = MDs.size();
|
BitcodeWriter: Emit uniqued subgraphs after all distinct nodes
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.
Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references. In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled. This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).
Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves. Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).
I've added two testcases:
- test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
instead of uniqued ones. This confirms that, in the absence of
uniqued nodes, distinct nodes are still emitted in post-order.
- test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
example where a naive post-order traversal would cause one uniqued
node to forward-reference another. IOW, it's the motivating test.
llvm-svn: 267278
2016-04-23 12:59:22 +08:00
|
|
|
|
|
|
|
// Flush out any delayed distinct nodes; these are all the distinct nodes
|
|
|
|
// that are leaves in last uniqued subgraph.
|
|
|
|
if (Worklist.empty() || Worklist.back().first->isDistinct()) {
|
|
|
|
for (const MDNode *N : DelayedDistinctNodes)
|
|
|
|
Worklist.push_back(std::make_pair(N, N->op_begin()));
|
|
|
|
DelayedDistinctNodes.clear();
|
|
|
|
}
|
2010-08-24 10:24:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
const MDNode *ValueEnumerator::enumerateMetadataImpl(unsigned F, const Metadata *MD) {
|
2016-04-19 11:46:51 +08:00
|
|
|
if (!MD)
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
return nullptr;
|
2016-04-19 11:46:51 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
assert(
|
|
|
|
(isa<MDNode>(MD) || isa<MDString>(MD) || isa<ConstantAsMetadata>(MD)) &&
|
|
|
|
"Invalid metadata kind");
|
2010-08-24 10:24:03 +08:00
|
|
|
|
2016-04-19 11:46:51 +08:00
|
|
|
auto Insertion = MetadataMap.insert(std::make_pair(MD, MDIndex(F)));
|
|
|
|
MDIndex &Entry = Insertion.first->second;
|
|
|
|
if (!Insertion.second) {
|
|
|
|
// Already mapped. If F doesn't match the function tag, drop it.
|
|
|
|
if (Entry.hasDifferentFunction(F))
|
|
|
|
dropFunctionFromMetadata(*Insertion.first);
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
return nullptr;
|
2016-04-19 11:46:51 +08:00
|
|
|
}
|
2014-10-22 06:13:34 +08:00
|
|
|
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
// Don't assign IDs to metadata nodes.
|
|
|
|
if (auto *N = dyn_cast<MDNode>(MD))
|
|
|
|
return N;
|
2015-01-13 06:30:34 +08:00
|
|
|
|
2016-04-02 23:22:57 +08:00
|
|
|
// Save the metadata.
|
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-10 02:38:53 +08:00
|
|
|
MDs.push_back(MD);
|
2016-04-19 11:46:51 +08:00
|
|
|
Entry.ID = MDs.size();
|
|
|
|
|
|
|
|
// Enumerate the constant, if any.
|
|
|
|
if (auto *C = dyn_cast<ConstantAsMetadata>(MD))
|
|
|
|
EnumerateValue(C->getValue());
|
2016-04-21 09:55:12 +08:00
|
|
|
|
ValueMapper/Enumerator: Clean up code in post-order traversals, NFC
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
llvm-svn: 267099
2016-04-22 10:33:06 +08:00
|
|
|
return nullptr;
|
2010-08-24 10:24:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// EnumerateFunctionLocalMetadataa - Incorporate function-local metadata
|
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-10 02:38:53 +08:00
|
|
|
/// information reachable from the metadata.
|
|
|
|
void ValueEnumerator::EnumerateFunctionLocalMetadata(
|
2016-04-02 23:22:57 +08:00
|
|
|
unsigned F, const LocalAsMetadata *Local) {
|
|
|
|
assert(F && "Expected a function");
|
|
|
|
|
2010-08-24 10:24:03 +08:00
|
|
|
// Check to see if it's already in!
|
2016-04-02 23:22:57 +08:00
|
|
|
MDIndex &Index = MetadataMap[Local];
|
|
|
|
if (Index.ID) {
|
|
|
|
assert(Index.F == F && "Expected the same function");
|
2009-08-04 14:00:18 +08:00
|
|
|
return;
|
2016-04-02 23:22:57 +08:00
|
|
|
}
|
2014-10-22 06:13:34 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
MDs.push_back(Local);
|
2016-04-02 23:22:57 +08:00
|
|
|
Index.F = F;
|
|
|
|
Index.ID = MDs.size();
|
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-10 02:38:53 +08:00
|
|
|
|
|
|
|
EnumerateValue(Local->getValue());
|
2009-08-04 14:00:18 +08:00
|
|
|
}
|
|
|
|
|
2016-04-23 12:42:39 +08:00
|
|
|
static unsigned getMetadataTypeOrder(const Metadata *MD) {
|
|
|
|
// Strings are emitted in bulk and must come first.
|
|
|
|
if (isa<MDString>(MD))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// ConstantAsMetadata doesn't reference anything. We may as well shuffle it
|
|
|
|
// to the front since we can detect it.
|
|
|
|
auto *N = dyn_cast<MDNode>(MD);
|
|
|
|
if (!N)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// The reader is fast forward references for distinct node operands, but slow
|
|
|
|
// when uniqued operands are unresolved.
|
|
|
|
return N->isDistinct() ? 2 : 3;
|
|
|
|
}
|
|
|
|
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
void ValueEnumerator::organizeMetadata() {
|
2016-04-02 23:22:57 +08:00
|
|
|
assert(MetadataMap.size() == MDs.size() &&
|
|
|
|
"Metadata map and vector out of sync");
|
|
|
|
|
|
|
|
if (MDs.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Copy out the index information from MetadataMap in order to choose a new
|
|
|
|
// order.
|
|
|
|
SmallVector<MDIndex, 64> Order;
|
|
|
|
Order.reserve(MetadataMap.size());
|
|
|
|
for (const Metadata *MD : MDs)
|
|
|
|
Order.push_back(MetadataMap.lookup(MD));
|
|
|
|
|
|
|
|
// Partition:
|
|
|
|
// - by function, then
|
|
|
|
// - by isa<MDString>
|
|
|
|
// and then sort by the original/current ID. Since the IDs are guaranteed to
|
|
|
|
// be unique, the result of std::sort will be deterministic. There's no need
|
|
|
|
// for std::stable_sort.
|
|
|
|
std::sort(Order.begin(), Order.end(), [this](MDIndex LHS, MDIndex RHS) {
|
2016-04-23 12:42:39 +08:00
|
|
|
return std::make_tuple(LHS.F, getMetadataTypeOrder(LHS.get(MDs)), LHS.ID) <
|
|
|
|
std::make_tuple(RHS.F, getMetadataTypeOrder(RHS.get(MDs)), RHS.ID);
|
2016-04-02 23:22:57 +08:00
|
|
|
});
|
|
|
|
|
|
|
|
// Rebuild MDs, index the metadata ranges for each function in FunctionMDs,
|
|
|
|
// and fix up MetadataMap.
|
|
|
|
std::vector<const Metadata *> OldMDs = std::move(MDs);
|
|
|
|
MDs.reserve(OldMDs.size());
|
|
|
|
for (unsigned I = 0, E = Order.size(); I != E && !Order[I].F; ++I) {
|
|
|
|
auto *MD = Order[I].get(OldMDs);
|
|
|
|
MDs.push_back(MD);
|
|
|
|
MetadataMap[MD].ID = I + 1;
|
|
|
|
if (isa<MDString>(MD))
|
|
|
|
++NumMDStrings;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return early if there's nothing for the functions.
|
|
|
|
if (MDs.size() == Order.size())
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
return;
|
|
|
|
|
2016-04-02 23:22:57 +08:00
|
|
|
// Build the function metadata ranges.
|
|
|
|
MDRange R;
|
|
|
|
FunctionMDs.reserve(OldMDs.size());
|
|
|
|
unsigned PrevF = 0;
|
|
|
|
for (unsigned I = MDs.size(), E = Order.size(), ID = MDs.size(); I != E;
|
|
|
|
++I) {
|
|
|
|
unsigned F = Order[I].F;
|
|
|
|
if (!PrevF) {
|
|
|
|
PrevF = F;
|
|
|
|
} else if (PrevF != F) {
|
|
|
|
R.Last = FunctionMDs.size();
|
|
|
|
std::swap(R, FunctionMDInfo[PrevF]);
|
|
|
|
R.First = FunctionMDs.size();
|
|
|
|
|
|
|
|
ID = MDs.size();
|
|
|
|
PrevF = F;
|
|
|
|
}
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
|
2016-04-02 23:22:57 +08:00
|
|
|
auto *MD = Order[I].get(OldMDs);
|
|
|
|
FunctionMDs.push_back(MD);
|
|
|
|
MetadataMap[MD].ID = ++ID;
|
|
|
|
if (isa<MDString>(MD))
|
|
|
|
++R.NumStrings;
|
|
|
|
}
|
|
|
|
R.Last = FunctionMDs.size();
|
|
|
|
FunctionMDInfo[PrevF] = R;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ValueEnumerator::incorporateFunctionMetadata(const Function &F) {
|
|
|
|
NumModuleMDs = MDs.size();
|
|
|
|
|
|
|
|
auto R = FunctionMDInfo.lookup(getValueID(&F) + 1);
|
|
|
|
NumMDStrings = R.NumStrings;
|
|
|
|
MDs.insert(MDs.end(), FunctionMDs.begin() + R.First,
|
|
|
|
FunctionMDs.begin() + R.Last);
|
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
llvm-svn: 264551
2016-03-28 07:17:54 +08:00
|
|
|
}
|
|
|
|
|
2010-01-15 03:54:11 +08:00
|
|
|
void ValueEnumerator::EnumerateValue(const Value *V) {
|
2009-12-31 08:51:46 +08:00
|
|
|
assert(!V->getType()->isVoidTy() && "Can't insert void values!");
|
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-10 02:38:53 +08:00
|
|
|
assert(!isa<MetadataAsValue>(V) && "EnumerateValue doesn't handle Metadata!");
|
2009-08-04 14:00:18 +08:00
|
|
|
|
2007-04-22 14:24:45 +08:00
|
|
|
// Check to see if it's already in!
|
|
|
|
unsigned &ValueID = ValueMap[V];
|
|
|
|
if (ValueID) {
|
|
|
|
// Increment use count.
|
|
|
|
Values[ValueID-1].second++;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
if (auto *GO = dyn_cast<GlobalObject>(V))
|
|
|
|
if (const Comdat *C = GO->getComdat())
|
|
|
|
Comdats.insert(C);
|
|
|
|
|
2007-05-06 09:00:28 +08:00
|
|
|
// Enumerate the type of this value.
|
|
|
|
EnumerateType(V->getType());
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-04-22 14:24:45 +08:00
|
|
|
if (const Constant *C = dyn_cast<Constant>(V)) {
|
|
|
|
if (isa<GlobalValue>(C)) {
|
|
|
|
// Initializers for globals are handled explicitly elsewhere.
|
2007-05-06 09:00:28 +08:00
|
|
|
} else if (C->getNumOperands()) {
|
|
|
|
// If a constant has operands, enumerate them. This makes sure that if a
|
|
|
|
// constant has uses (for example an array of const ints), that they are
|
|
|
|
// inserted also.
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-05-06 09:00:28 +08:00
|
|
|
// We prefer to enumerate them with values before we enumerate the user
|
|
|
|
// itself. This makes it more likely that we can avoid forward references
|
|
|
|
// in the reader. We know that there can be no cycles in the constants
|
|
|
|
// graph that don't go through a global variable.
|
2007-04-22 14:24:45 +08:00
|
|
|
for (User::const_op_iterator I = C->op_begin(), E = C->op_end();
|
|
|
|
I != E; ++I)
|
2009-11-01 09:27:45 +08:00
|
|
|
if (!isa<BasicBlock>(*I)) // Don't enumerate BB operand to BlockAddress.
|
2010-01-15 03:54:11 +08:00
|
|
|
EnumerateValue(*I);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-05-06 09:00:28 +08:00
|
|
|
// Finally, add the value. Doing this could make the ValueID reference be
|
|
|
|
// dangling, don't reuse it.
|
2009-05-11 04:57:05 +08:00
|
|
|
Values.push_back(std::make_pair(V, 1U));
|
|
|
|
ValueMap[V] = Values.size();
|
|
|
|
return;
|
2009-07-23 09:07:34 +08:00
|
|
|
}
|
|
|
|
}
|
2009-05-11 04:57:05 +08:00
|
|
|
|
2007-05-06 09:00:28 +08:00
|
|
|
// Add the value.
|
|
|
|
Values.push_back(std::make_pair(V, 1U));
|
|
|
|
ValueID = Values.size();
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
void ValueEnumerator::EnumerateType(Type *Ty) {
|
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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
unsigned *TypeID = &TypeMap[Ty];
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2011-04-07 00:49:37 +08:00
|
|
|
// We've already seen this type.
|
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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
if (*TypeID)
|
2007-04-22 14:24:45 +08:00
|
|
|
return;
|
2009-09-20 10:20:51 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// If it is a non-anonymous struct, mark the type as being visited so that we
|
|
|
|
// don't recursively visit it. This is safe because we allow forward
|
|
|
|
// references of these in the bitcode reader.
|
2011-07-18 12:54:35 +08:00
|
|
|
if (StructType *STy = dyn_cast<StructType>(Ty))
|
2011-08-13 02:06:37 +08:00
|
|
|
if (!STy->isLiteral())
|
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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
*TypeID = ~0U;
|
2012-11-25 23:23:39 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Enumerate all of the subtypes before we enumerate this type. This ensures
|
|
|
|
// that the type will be enumerated in an order that can be directly built.
|
2014-11-25 04:44:36 +08:00
|
|
|
for (Type *SubTy : Ty->subtypes())
|
|
|
|
EnumerateType(SubTy);
|
2012-11-25 23:23:39 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Refresh the TypeID pointer in case the table rehashed.
|
|
|
|
TypeID = &TypeMap[Ty];
|
2012-11-25 23:23:39 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Check to see if we got the pointer another way. This can happen when
|
|
|
|
// enumerating recursive types that hit the base case deeper than they start.
|
|
|
|
//
|
|
|
|
// If this is actually a struct that we are treating as forward ref'able,
|
|
|
|
// then emit the definition now that all of its contents are available.
|
|
|
|
if (*TypeID && *TypeID != ~0U)
|
|
|
|
return;
|
2012-11-25 23:23:39 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Add this type now that its contents are all happily enumerated.
|
|
|
|
Types.push_back(Ty);
|
2012-11-25 23:23:39 +08: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.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
*TypeID = Types.size();
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
|
|
|
|
2007-05-06 16:35:19 +08:00
|
|
|
// Enumerate the types for the specified value. If the value is a constant,
|
|
|
|
// walk through it, enumerating the types of the constant.
|
2010-01-15 03:54:11 +08:00
|
|
|
void ValueEnumerator::EnumerateOperandType(const Value *V) {
|
2007-05-06 16:35:19 +08:00
|
|
|
EnumerateType(V->getType());
|
2012-11-25 23:23:39 +08:00
|
|
|
|
2016-03-28 08:03:12 +08:00
|
|
|
assert(!isa<MetadataAsValue>(V) && "Unexpected metadata operand");
|
2012-11-25 23:23:39 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
const Constant *C = dyn_cast<Constant>(V);
|
|
|
|
if (!C)
|
|
|
|
return;
|
2012-11-25 23:23:39 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
// If this constant is already enumerated, ignore it, we know its type must
|
|
|
|
// be enumerated.
|
|
|
|
if (ValueMap.count(C))
|
|
|
|
return;
|
2009-05-11 04:57:05 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
// This constant may have operands, make sure to enumerate the types in
|
|
|
|
// them.
|
2015-06-26 04:51:38 +08:00
|
|
|
for (const Value *Op : C->operands()) {
|
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-10 02:38:53 +08:00
|
|
|
// Don't enumerate basic blocks here, this happens as operands to
|
|
|
|
// blockaddress.
|
|
|
|
if (isa<BasicBlock>(Op))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
EnumerateOperandType(Op);
|
|
|
|
}
|
2007-05-06 16:35:19 +08:00
|
|
|
}
|
|
|
|
|
2013-02-12 16:01:22 +08:00
|
|
|
void ValueEnumerator::EnumerateAttributes(AttributeSet PAL) {
|
2008-03-13 01:45:29 +08:00
|
|
|
if (PAL.isEmpty()) return; // null is always 0.
|
2013-02-12 16:01:22 +08:00
|
|
|
|
2007-05-04 06:46:43 +08:00
|
|
|
// Do a lookup.
|
2013-02-12 16:01:22 +08:00
|
|
|
unsigned &Entry = AttributeMap[PAL];
|
2007-05-04 06:46:43 +08:00
|
|
|
if (Entry == 0) {
|
|
|
|
// Never saw this before, add it.
|
2012-12-19 15:18:57 +08:00
|
|
|
Attribute.push_back(PAL);
|
|
|
|
Entry = Attribute.size();
|
2007-05-04 06:46:43 +08:00
|
|
|
}
|
2013-02-11 07:06:02 +08:00
|
|
|
|
|
|
|
// Do lookups for all attribute groups.
|
|
|
|
for (unsigned i = 0, e = PAL.getNumSlots(); i != e; ++i) {
|
|
|
|
AttributeSet AS = PAL.getSlotAttributes(i);
|
2013-02-12 06:33:26 +08:00
|
|
|
unsigned &Entry = AttributeGroupMap[AS];
|
2013-02-11 07:06:02 +08:00
|
|
|
if (Entry == 0) {
|
2013-02-12 06:33:26 +08:00
|
|
|
AttributeGroups.push_back(AS);
|
|
|
|
Entry = AttributeGroups.size();
|
2013-02-11 07:06:02 +08:00
|
|
|
}
|
|
|
|
}
|
2007-05-04 06:46:43 +08:00
|
|
|
}
|
|
|
|
|
2011-06-04 01:02:19 +08:00
|
|
|
void ValueEnumerator::incorporateFunction(const Function &F) {
|
2010-02-25 16:30:17 +08:00
|
|
|
InstructionCount = 0;
|
2007-04-26 13:53:54 +08:00
|
|
|
NumModuleValues = Values.size();
|
2016-04-02 23:22:57 +08:00
|
|
|
|
|
|
|
// Add global metadata to the function block. This doesn't include
|
|
|
|
// LocalAsMetadata.
|
|
|
|
incorporateFunctionMetadata(F);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-04-26 11:50:57 +08:00
|
|
|
// Adding function arguments to the value table.
|
2015-10-13 11:26:19 +08:00
|
|
|
for (const auto &I : F.args())
|
|
|
|
EnumerateValue(&I);
|
2007-04-26 11:50:57 +08:00
|
|
|
|
2007-04-26 13:53:54 +08:00
|
|
|
FirstFuncConstantID = Values.size();
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-04-26 11:50:57 +08:00
|
|
|
// Add all function-level constants to the value table.
|
2015-10-13 11:26:19 +08:00
|
|
|
for (const BasicBlock &BB : F) {
|
|
|
|
for (const Instruction &I : BB)
|
|
|
|
for (const Use &OI : I.operands()) {
|
|
|
|
if ((isa<Constant>(OI) && !isa<GlobalValue>(OI)) || isa<InlineAsm>(OI))
|
|
|
|
EnumerateValue(OI);
|
2007-04-26 11:50:57 +08:00
|
|
|
}
|
2015-10-13 11:26:19 +08:00
|
|
|
BasicBlocks.push_back(&BB);
|
|
|
|
ValueMap[&BB] = BasicBlocks.size();
|
2007-04-26 11:50:57 +08:00
|
|
|
}
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-05-04 13:21:47 +08:00
|
|
|
// Optimize the constant layout.
|
|
|
|
OptimizeConstants(FirstFuncConstantID, Values.size());
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-11-27 21:23:08 +08:00
|
|
|
// Add the function's parameter attributes so they are available for use in
|
|
|
|
// the function's instruction.
|
2008-09-26 05:00:45 +08:00
|
|
|
EnumerateAttributes(F.getAttributes());
|
2007-11-27 21:23:08 +08:00
|
|
|
|
2007-04-26 13:53:54 +08:00
|
|
|
FirstInstID = Values.size();
|
2009-09-20 10:20:51 +08: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.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallVector<LocalAsMetadata *, 8> FnLocalMDVector;
|
2007-04-26 11:50:57 +08:00
|
|
|
// Add all of the instructions.
|
2015-10-13 11:26:19 +08:00
|
|
|
for (const BasicBlock &BB : F) {
|
|
|
|
for (const Instruction &I : BB) {
|
|
|
|
for (const Use &OI : I.operands()) {
|
|
|
|
if (auto *MD = dyn_cast<MetadataAsValue>(&OI))
|
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-10 02:38:53 +08:00
|
|
|
if (auto *Local = dyn_cast<LocalAsMetadata>(MD->getMetadata()))
|
2010-02-04 09:13:08 +08:00
|
|
|
// Enumerate metadata after the instructions they might refer to.
|
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-10 02:38:53 +08:00
|
|
|
FnLocalMDVector.push_back(Local);
|
2010-08-24 10:24:03 +08:00
|
|
|
}
|
2012-11-25 23:23:39 +08:00
|
|
|
|
2015-10-13 11:26:19 +08:00
|
|
|
if (!I.getType()->isVoidTy())
|
|
|
|
EnumerateValue(&I);
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
|
|
|
}
|
2010-02-04 09:13:08 +08:00
|
|
|
|
|
|
|
// Add all of the function-local metadata.
|
2016-07-08 09:13:41 +08:00
|
|
|
for (unsigned i = 0, e = FnLocalMDVector.size(); i != e; ++i) {
|
|
|
|
// At this point, every local values have been incorporated, we shouldn't
|
|
|
|
// have a metadata operand that references a value that hasn't been seen.
|
|
|
|
assert(ValueMap.count(FnLocalMDVector[i]->getValue()) &&
|
|
|
|
"Missing value for metadata operand");
|
2016-04-02 23:22:57 +08:00
|
|
|
EnumerateFunctionLocalMetadata(F, FnLocalMDVector[i]);
|
2016-07-08 09:13:41 +08:00
|
|
|
}
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
|
|
|
|
2011-06-04 01:02:19 +08:00
|
|
|
void ValueEnumerator::purgeFunction() {
|
2007-04-26 11:50:57 +08:00
|
|
|
/// Remove purged values from the ValueMap.
|
2007-04-26 13:53:54 +08:00
|
|
|
for (unsigned i = NumModuleValues, e = Values.size(); i != e; ++i)
|
2007-04-26 11:50:57 +08:00
|
|
|
ValueMap.erase(Values[i].first);
|
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-10 02:38:53 +08:00
|
|
|
for (unsigned i = NumModuleMDs, e = MDs.size(); i != e; ++i)
|
2015-12-30 07:00:22 +08:00
|
|
|
MetadataMap.erase(MDs[i]);
|
2007-04-26 12:42:16 +08:00
|
|
|
for (unsigned i = 0, e = BasicBlocks.size(); i != e; ++i)
|
|
|
|
ValueMap.erase(BasicBlocks[i]);
|
2009-09-20 10:20:51 +08:00
|
|
|
|
2007-04-26 13:53:54 +08:00
|
|
|
Values.resize(NumModuleValues);
|
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-10 02:38:53 +08:00
|
|
|
MDs.resize(NumModuleMDs);
|
2007-04-26 12:42:16 +08:00
|
|
|
BasicBlocks.clear();
|
2016-04-02 23:22:57 +08:00
|
|
|
NumMDStrings = 0;
|
2007-04-22 14:24:45 +08:00
|
|
|
}
|
2009-10-28 13:24:40 +08:00
|
|
|
|
|
|
|
static void IncorporateFunctionInfoGlobalBBIDs(const Function *F,
|
|
|
|
DenseMap<const BasicBlock*, unsigned> &IDMap) {
|
|
|
|
unsigned Counter = 0;
|
2015-10-13 11:26:19 +08:00
|
|
|
for (const BasicBlock &BB : *F)
|
|
|
|
IDMap[&BB] = ++Counter;
|
2009-10-28 13:24:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// getGlobalBasicBlockID - This returns the function-specific ID for the
|
|
|
|
/// specified basic block. This is relatively expensive information, so it
|
|
|
|
/// should only be used by rare constructs such as address-of-label.
|
|
|
|
unsigned ValueEnumerator::getGlobalBasicBlockID(const BasicBlock *BB) const {
|
|
|
|
unsigned &Idx = GlobalBasicBlockIDs[BB];
|
|
|
|
if (Idx != 0)
|
2009-11-01 09:27:45 +08:00
|
|
|
return Idx-1;
|
2009-10-28 13:24:40 +08:00
|
|
|
|
|
|
|
IncorporateFunctionInfoGlobalBBIDs(BB->getParent(), GlobalBasicBlockIDs);
|
|
|
|
return getGlobalBasicBlockID(BB);
|
|
|
|
}
|
2015-02-25 08:51:52 +08:00
|
|
|
|
|
|
|
uint64_t ValueEnumerator::computeBitsRequiredForTypeIndicies() const {
|
|
|
|
return Log2_32_Ceil(getTypes().size() + 1);
|
|
|
|
}
|