This is an archive of the discontinued LLVM Phabricator instance.

[OpaquePtr] Support call instruction
ClosedPublic

Authored by nikic on Jun 22 2021, 1:02 PM.

Details

Reviewers
aeubanks
Group Reviewers
Restricted Project
Commits
rGf660af46e3df: [OpaquePtr] Support call instruction
Summary

Add support for call of opaque pointer, currently only possible for indirect calls.

Diff Detail

Event Timeline

nikic created this revision.Jun 22 2021, 1:02 PM
nikic requested review of this revision.Jun 22 2021, 1:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 22 2021, 1:02 PM
arsenm added a subscriber: arsenm.Jun 22 2021, 1:32 PM
arsenm added inline comments.
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

nikic updated this revision to Diff 353777.Jun 22 2021, 1:56 PM

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 :/

aeubanks added inline comments.Jun 22 2021, 2:12 PM
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

nikic updated this revision to Diff 353789.Jun 22 2021, 2:25 PM

Use getWithSamePointeeType().

nikic added inline comments.Jun 22 2021, 2:27 PM
llvm/lib/AsmParser/LLParser.cpp
1482

I've changed it to use getWithSamePointeeType() instead. It's not possible to actually trigger this case right now, because Ty currently can't be opaque (would need D103503). Only ValTy can be opaque.

aeubanks accepted this revision.Jun 23 2021, 9:53 AM

at some point, this might not be necessary if all function pointers become opaque pointers, right?
but for now we do need this

This revision is now accepted and ready to land.Jun 23 2021, 9:53 AM
nikic added a comment.Jun 23 2021, 9:55 AM

at some point, this might not be necessary if all function pointers become opaque pointers, right?
but for now we do need this

Yeah, the LLParser part wouldn't be needed with opaque function pointers.

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 :/

Interesting; given that there are two uses of %p maybe one of them isn't being tracked. Did you investigate?

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 :/

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.

This revision was landed with ongoing or failed builds.Jun 23 2021, 11:18 AM
This revision was automatically updated to reflect the committed changes.

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.