[PATCH] D147714: [Attr] Introduce [[clang::nonportable_musttail]] as less strict version of [[clang::musttail]]

[Josh Haberman via Phabricator via cfe-commits]

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