[PATCH] D102612: SwiftTailCC: teach verifier musttail rules applicable to this CC.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
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
----------------
t.p.northover wrote:
> efriedma wrote:
> > t.p.northover wrote:
> > > efriedma wrote:
> > > > 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.
> > > Return type promotion seems really iffy with tail calls even now. For this module:
> > > 
> > > ```declare [16 x i64] @foo()
> > > 
> > > define [16 x i64] @bar() {
> > >   %res = musttail call [16 x i64] @foo()
> > >   ret [16 x i64] %res
> > > }```
> > > 
> > > AArch64 & ARM don't actually do a tail call but are otherwise correct (no diagnostic because of where the check is; this patch fixes that). X86 does the tail call but tells `@foo` to use a random bit of `@bar`'s caller's stack for the array.
> > > 
> > > I don't think the verifier can check that though, it's quite entwined in CodeGen and Verifier.cpp has nothing but a `TargetTriple` to work with.
> > > 
> > > Best I can think of is to document that functions with return type promotion probably won't work as expected here.
> > If the return types match, it's easy to do the "right" thing: we just need to forward the indirect pointer.
> > 
> > It's not high priority to implement, but I'd at least like an appropriate error.  And I'm concerned if we don't have any idea how to implement it.  I guess one thing we could do is allow passing a null pointer for the promoted return value, and add a null check in the callee before storing the value.
> Fair enough, I'll make the X86 backend give an error instead of assuming it knows better than SDAG for now.
I'd also like to see testcases that show we generate the expected "failed to perform tail call elimination" error for the unimplemented cases.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102612/new/

https://reviews.llvm.org/D102612