[PATCH] D106013: [Verifier] Require same signature for intrinsic calls

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 15 09:36:34 PDT 2021


nikic added a comment.

Looks like the new verifier rule triggers on some ObjCARC tests, for example:

  Intrinsic called with incompatible signature
    %call21 = call signext i8 bitcast (i8* (i8*, i8*, ...)* @llvm.objc.msgSend to i8 (i8*, i8*)*)(i8* %call137, i8* %tmp19)
  Intrinsic called with incompatible signature
    %call51 = call %struct._NSRange bitcast (i8* (i8*, i8*, ...)* @llvm.objc.msgSend to %struct._NSRange (i8*, i8*, i64, i64)*)(i8* %call137, i8* %tmp49, i64 0, i64 0)
  Intrinsic called with incompatible signature
    %call66 = call signext i8 bitcast (i8* (i8*, i8*, ...)* @llvm.objc.msgSend to i8 (i8*, i8*, %1*)*)(i8* %call6110, i8* %tmp64, %1* bitcast (%struct.NSConstantString* @_unnamed_cfstring_44 to %1*))
  Intrinsic called with incompatible signature
    %call84 = call signext i8 bitcast (i8* (i8*, i8*, ...)* @llvm.objc.msgSend to i8 (i8*, i8*)*)(i8* %filename.0.in, i8* %tmp82)

Not entirely sure what to do here. This code only works because `llvm.objc.msgSend` is not an actual registered intrinsic, which means that taking it's address is not prohibited by the verifier. For "real" intrinsics, the bitcast would already error.

So should I relax the check to just `isIntrinsic()` callees, or should I try to adjust those ObjCARC tests to drop the bitcast? It seems like the issue is with the input IR, not the transform, and check-clang passes, so it doesn't look like this IR is generated by the frontend.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106013



More information about the llvm-commits mailing list