[PATCH] D102612: SwiftTailCC: teach verifier musttail rules applicable to this CC.
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon May 17 13:08:23 PDT 2021
efriedma added a comment.
> Why doesn't the count and sequence of arguments/parameters have to match for swifttail calls?
tailcc/swifttailcc use a callee-pop convention, so we can allocate as much stack space as we need for arguments.
We might want to consider relaxing the rules for tailcc as well as swifttailcc, but I guess it doesn't need to happen in this patch.
================
Comment at: llvm/docs/LangRef.rst:11339
- The ret instruction must return the (possibly bitcasted) value
- produced by the call or void.
- - The caller and callee prototypes must match. Pointer types of
- parameters or return types may differ in pointee type, but not
- in address space.
+ produced by the call, undef, or void.
+ - The caller and callee prototypes must match if the calling convention is
----------------
There's one source of complexity related to allowing undef here you might not have considered: return type promotion (converting a large return value to an indirect argument). In particular, if we need to promote the return type of the musttail call. I think you can make this work, but not sure if targets generate the right sequence.
================
Comment at: llvm/docs/LangRef.rst:11347
+ calls, instead only a limited set of these attributes is allowed: sret,
+ byval, swiftself, and swiftasync
- The callee must be varargs iff the caller is varargs. Bitcasting a
----------------
The way this is organized is hard to read: can you rearrange it to separate the common, non-swittailcc, and the swifttailcc requirements?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D102612/new/
https://reviews.llvm.org/D102612
More information about the llvm-commits
mailing list