Add support for call of opaque pointer, currently only possible for indirect calls.
Details
- Reviewers
aeubanks - Group Reviewers
Restricted Project - Commits
- rGf660af46e3df: [OpaquePtr] Support call instruction
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/lib/AsmParser/LLParser.cpp | ||
|---|---|---|
| 1479–1480 | This comment doesn't make sense, it reads like the address space and opaque pointers are mutually exclusive things | |
could you add a test for a call with arguments?
| llvm/lib/AsmParser/LLParser.cpp | ||
|---|---|---|
| 1480 | we still need to check the address space like below | |
Preserve address space check, add test with argument.
While doing the latter, I found out that
define void @call(void (...)* %p) {
call void (...) %p(void (...)* %p)
ret void
}fails verify-uselistorder (independently of this patch). I happened to use that as the first thing I tried :/
| llvm/lib/AsmParser/LLParser.cpp | ||
|---|---|---|
| 1482 | if we have an opaque pointer of a wrong address space, we could get past the first CheckType(), then call getElementType() on the opaque pointer type below | |
at some point, this might not be necessary if all function pointers become opaque pointers, right?
but for now we do need this
Interesting; given that there are two uses of %p maybe one of them isn't being tracked. Did you investigate?
Looks like it's caused by this:
void CallInst::init(FunctionType *FTy, Value *Func, ArrayRef<Value *> Args,
ArrayRef<OperandBundleDef> Bundles, const Twine &NameStr) {
// ...
setCalledOperand(Func);
// ...
llvm::copy(Args, op_begin());
// ...
}and
/// The last operand is the called operand.
static constexpr int CalledOperandOpEndIdx = -1;
void setCalledOperand(Value *V) { Op<CalledOperandOpEndIdx>() = V; }The use-list order "predictors" in BitcodeWriter and AsmWriter assume that operands will be initialized in order. Moving the call to setCalledOperand after the llvm::copy fixes it.
I'll look for other similar bugs and post a patch.
Posted https://reviews.llvm.org/D104805. Once that lands, verify-uselistorder should work for your original testcase.
This comment doesn't make sense, it reads like the address space and opaque pointers are mutually exclusive things