[PATCH] D41335: [InlineFunction] Inline vararg functions that do not access varargs.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 19 13:38:19 PST 2017


fhahn added a comment.

In https://reviews.llvm.org/D41335#959952, @efriedma wrote:

> We should probably clarify LangRef for musttail to make it clear what transforms are legal.  (Does the "thunk" attribute matter?)


I think for this optimization, what matters is the fact that we need to forward the varargs from the call site to the musttail function. Although I am not sure if the following statement  from the LangRef is very clear about the forwarding behaviour. Is it worth clarifying that?

> Both markers imply that the callee does not access allocas or varargs from the caller.
>  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.





================
Comment at: lib/Transforms/Utils/InlineFunction.cpp:1516
+            return false;
+          }))
+        return false;
----------------
efriedma wrote:
> Does the comment from https://reviews.llvm.org/D22529#488888, about doing this check during the inline cost scan, still apply here?
Ah thanks, I was not aware of D22529. I can move the check to the inline cost scan. The only potential problem could be that the inline cost check can be disabled AFAIK and then this would affect legality.


https://reviews.llvm.org/D41335





More information about the llvm-commits mailing list