[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 ↗

(On Diff #129072)

Do we need to fix this paragraph?

9053 ↗

(On Diff #129072)

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

llvm/trunk/docs/LangRef.rst

#. The optional ``tail`` and ``musttail`` markers indicate that the optimizers
    means that the call must be tail call optimized in order for the program to
    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:
+   Both markers imply that the callee does not access allocas from the caller.
+   The ``tail`` marker additionally implies that the callee does not access
+   varargs from the caller, while ``musttail`` implies that varargs from the
+   caller are passed to the callee. 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.