[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