[PATCH] D104740: [OpaquePtr] Support call instruction

[Duncan P. N. Exon Smith via Phabricator via llvm-commits]

dexonsmith added a comment.

In D104740#2836407 <https://reviews.llvm.org/D104740#2836407>, @dexonsmith wrote:

> In D104740#2834433 <https://reviews.llvm.org/D104740#2834433>, @nikic wrote:
>
>> 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.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104740/new/

https://reviews.llvm.org/D104740