[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