[PATCH] D11856: LowerBitSets: Extend pass to support functions as bitset members.
JF Bastien via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 18 10:58:37 PDT 2015
jfb added inline comments.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:227
@@ -223,2 +226,3 @@
// Mapping from bitset mdstrings to the call sites that test them.
+ DenseMap<Metadata *, std::vector<CallInst *>> BitSetTestCallSites;
----------------
Comment is out of date.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:571
@@ +570,3 @@
+ Constant *CombinedGlobalIdxs[] = {ConstantInt::get(Int32Ty, 0),
+ ConstantInt::get(Int32Ty, I * 2)};
+ Constant *CombinedGlobalElemPtr = ConstantExpr::getGetElementPtr(
----------------
I'm not sure I understand padding elements. Could you explain further?
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:579
@@ +578,3 @@
+ GlobalAlias::create(Globals[I]->getType(), Globals[I]->getLinkage(),
+ "", CombinedGlobalElemPtr, M);
+ GAlias->takeName(Globals[I]);
----------------
Does this work with thread-local globals?
I'm also a bit worried about visibility / section / linkage type, but I may be misunderstanding the implications of what this patch adds.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:589
@@ +588,3 @@
+ if (Arch != Triple::x86 && Arch != Triple::x86_64)
+ report_fatal_error("Unsupported architecture for jump tables");
+
----------------
Could this be a virtual function instead? `report_fatal_error` by default, and only implemented for x86. I'm assuming the creation will also need to be specialized.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:651
@@ +650,3 @@
+void LowerBitSets::buildBitSetsFromFunctions(
+ ArrayRef<Metadata *> BitSets, ArrayRef<Function *> Globals) {
+ // This simple layout is based on the regular layout of jump tables.
----------------
Can Globals ever be empty? It seems a bit silly, but not entirely unlikely if someone just runs the pass.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:666
@@ +665,3 @@
+ FunctionType::get(Type::getVoidTy(M->getContext()), /*isVarArg=*/false),
+ Function::PrivateLinkage, "", M);
+ BasicBlock *BB = BasicBlock::Create(M->getContext(), "", NewFn);
----------------
Give it some dummy internal name starting with `__` so it's easier to figure things out. I'm assuming there's a test that'll check for that function name too.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:695
@@ +694,3 @@
+ // references to the original functions with references to the aliases.
+ for (unsigned I = 0; I != Globals.size()-1; ++I) {
+ Constant *CombinedGlobalElemPtr = ConstantExpr::getIntToPtr(
----------------
`clang-format`, here and a few other places.
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:889
@@ +888,3 @@
+ // Order bitsets by BitSetNM index for determinism.
+ std::sort(BitSets.begin(), BitSets.end(), [&](Metadata *M1, Metadata *M2) {
+ return BitSetIdIndices[M1] < BitSetIdIndices[M2];
----------------
IIUC duplicate indices can't occur?
================
Comment at: lib/Transforms/IPO/LowerBitSets.cpp:906
@@ -739,1 +905,3 @@
+ reinterpret_cast<Function **>(OrderedGlobals.data() +
+ OrderedGlobals.size())));
}
----------------
Eek, the above lines make me cry. LLVM doesn't have a way to create `ArrayRef` taking into account its magical type hierarchy? It would be nice to avoid the `reinterpret_cast` here, since it relies heavily on the `GlobalObject` / `GlobalVariable` / `Function` class hierarchy layout...
http://reviews.llvm.org/D11856
More information about the llvm-commits
mailing list