[PATCH] D98481: [Inliner] Do not inline mutual-recursive functions to avoid exponential size growth.

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 16 21:54:41 PDT 2021


On Tue, Mar 16, 2021 at 9:36 PM Wenlei He via Phabricator <
reviews at reviews.llvm.org> wrote:

> wenlei added a comment.
>
> In D98481#2630691 <https://reviews.llvm.org/D98481#2630691>, @davidxl
> wrote:
>
> > Hiroshi is working on the implementation, and I expect upstreaming
> happening soon. In a nutshell, the working set analysis is based on
> building interprocedural loop graph (ILG) and working set propagation.
>
> Looking forward to it. Interesting to see how accurately we can model
> working set.
>
> > Yes what you describe about the option sounds reasonable, though I am
> not sure about warning. Some -Rpass-analysis or -Rpass-missed message or
> some debug output seem better.
>
> The warning is to make people aware this is happening. Service developers
> don't use pass remarks, and pass remarks can also be a bit noisy.
>
>
Since the user explicitly uses the option to limit the inlining, the fact
that some inlines will be cutoff will be expected. To get what callstes are
cut off due to what reasons, -Rpass-missed seems natural for it.

Using warning has an unwanted behavior -- some build systems explicitly
turn warnings into errors. Failing the build by using the option defeats
the purpose.

If we are concerned about the negative impact of the option,  we can make
the option take a function name so that  the cap only applies to the
specified caller.

David




> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D98481/new/
>
> https://reviews.llvm.org/D98481
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210316/735962d0/attachment.html>


More information about the llvm-commits mailing list