[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
Wed Mar 17 13:05:45 PDT 2021
On Wed, Mar 17, 2021 at 12:13 PM Wenlei He via Phabricator <
reviews at reviews.llvm.org> wrote:
> wenlei added a comment.
>
> I think size cap might be better than call site counts, and query inliner
> instr size should not have cost.
>
> 2nd thought on the warning, how about this. The goal is help save time for
> everyone.
>
> - One switch for -inline-size-limit, default to huge value (could be
> INT_MAX). When the limit is hit, we emit a warning, but don’t stop
> inlining. This make it obvious to everyone when cgscc inlining is causing
> extremely long build time. With default to huge value, it should not fire
> at all so nothing would break due to warning as error. But people may
> choose to set a lower value (e.g. we may use a lower value internally, it
> may break build, but the hope is to capture extremely slow builds and
> bloated codegen quickly)
> - Another switch to -stop-inline-for-size-limit, default to off. When this
> is enabled, cgscc inline will stop when the above size limit is hit, no
> warning is issued since this is asked by user explicitly. This serves as a
> possible mitigation for bloated inlining without changing global threshold,
> and it's also cohesive with #1.
>
>
This SGTM.
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/20210317/bbe6d9d4/attachment.html>
More information about the llvm-commits
mailing list