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

[Wenlei He via llvm-commits]

Fair point. I was hoping to force a trace somewhere when this happens, and yes we’ll need to skip treat this warning as error which should prevent abuse to some extent.

I think we can just live without the warning for now. Passing function name through switch introduces coupling between build flags and source, which is not ideal, and can also be fragile.

From: Xinliang David Li <davidxl at google.com>
Date: Tuesday, March 16, 2021 at 9:54 PM
To: Wenlei He <reviews+D98481+public+2d824aa1c1081e47 at reviews.llvm.org>
Cc: Hongtao Yu <hoy at fb.com>, Wenlei He <wenlei at fb.com>, Kazu Hirata <kazu at google.com>, Chandler Carruth <chandlerc at gmail.com>, Wei Mi <wmi at google.com>, Easwaran Raman <eraman at google.com>, llvm-commits <llvm-commits at lists.llvm.org>, bhuvanendra.kumarn at amd.com <bhuvanendra.kumarn at amd.com>, 88888yl at gmail.com <88888yl at gmail.com>, dougpuob at gmail.com <dougpuob at gmail.com>, David Green <david.green at arm.com>
Subject: Re: [PATCH] D98481: [Inliner] Do not inline mutual-recursive functions to avoid exponential size growth.


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

In D98481#2630691 <https://reviews.llvm.org/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/new/>

https://reviews.llvm.org/D98481<https://reviews.llvm.org/D98481>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210317/08bd5226/attachment.html>