haberman added a comment. Correct me if I am wrong, but won't this produce LLVM IR that fails to validate?
The checks that exist today for `[[clang::musttail]]` are necessary to follow LLVM's rules about where `musttail` may appear: https://llvm.org/docs/LangRef.html#id328 > Calls marked musttail must obey the following additional rules: > > - The call must immediately precede a ret instruction, or a pointer bitcast > followed by a ret instruction. > - The ret instruction must return the (possibly bitcasted) value produced by > the call, undef, or void. > - The calling conventions of the caller and callee must match. > - The callee must be varargs iff the caller is varargs. Bitcasting a > non-varargs function to the appropriate varargs type is legal so long as the > non-varargs prefixes obey the other rules. > - The return type must not undergo automatic conversion to an sret pointer. > > In addition, if the calling convention is not swifttailcc or tailcc: > > - All ABI-impacting function attributes, such as sret, byval, inreg, > returned, and inalloca, must match. > - The caller and callee prototypes must match. Pointer types of parameters or > return types may differ in pointee type, but not in address space. It looks like this change would allow users to produce LLVM IR that violates that final condition: > The caller and callee prototypes must match. Pointer types of parameters or > return types may differ in pointee type, but not in address space. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147714/new/ https://reviews.llvm.org/D147714 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
