[LangRef] Clarify Varargs forwarding for musttail calls.

[fhahn]

Summary

This clarification was suggested by @efriedma in D41335, which uses this
behavior to inline musttail calls with varargs.

[efriedma]

docs/LangRef.rst

9037

Do we need to fix this paragraph?

9053

It would probably be more clear to separate out the bitcasting part; it isn't really a rule, just a consequence of the way bitcasting works.

[fhahn]

Thanks Eli! I've updated the initial paragraph to be explicit about what happens with varargs for tail/musttail. It is slightly more verbose, but I hope it is clearer now. I have left the varargs type rule unchanged for now.

[rnk]

lgtm

docs/LangRef.rst

#. The optional ``tail`` and ``musttail`` markers indicate that the optimizers
    be correct. The ``musttail`` marker provides these guarantees:
 
    #. The call will not cause unbounded stack growth if it is part of a
       recursive cycle in the call graph.
    #. Arguments with the :ref:`inalloca <attr_inalloca>` attribute are
       forwarded in place.
 
    Both markers imply that the callee does not access allocas or varargs from
    the caller. Calls marked ``musttail`` must obey the following additional
    rules:
 
    - The call must immediately precede a :ref:`ret <i_ret>` instruction,
      or a pointer bitcast followed by a ret instruction.
    - 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.
    - The calling conventions of the caller and callee must match.
    - All ABI-impacting function attributes, such as sret, byval, inreg,
      returned, and inalloca, 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 callee must be varargs iff the caller is varargs. If the callee is
+     varargs, the varargs passed to the caller will get passed to the callee
+     too. Bitcasting a non-varargs function to the appropriate varargs type is
+     legal so long as the non-varargs prefixes obey the other rules.
 
    Tail call optimization for calls marked ``tail`` is guaranteed to occur if
    the following conditions are met:
 
    -  Caller and callee both have the calling convention ``fastcc``.
    -  The call is in tail position (ret immediately follows call and ret
       uses value of call or is void).
    -  Option ``-tailcallopt`` is enabled, or