[PATCH] D91567: [llvm][inliner] Reuse the inliner pass to implement 'always inliner'

[Mircea Trofin via Phabricator via llvm-commits]

mtrofin added a comment.

In D91567#2403544 <https://reviews.llvm.org/D91567#2403544>, @aeubanks wrote:

> In D91567#2403252 <https://reviews.llvm.org/D91567#2403252>, @mtrofin wrote:
>
>> In D91567#2403236 <https://reviews.llvm.org/D91567#2403236>, @aeubanks wrote:
>>
>>> One thing that would be nice would be to have both inliners in the same CGSCC pass manager to avoid doing SCC construction twice, but that would require some shuffling of module/cgscc passes in ModuleInlinerWrapperPass. Maybe as a future cleanup.
>>
>> There's that benefit to simplifying the module with the always inliner before doing inlining "in earnest" I was pointing earlier at: for the ML policies work, we plan on capturing (sub)graph information. Using the same SCC would not help because the "higher" (callers) parts of the graph would have these mandatory inlinings not completed yet, and thus offer a less accurate picture of the problem space.
>
> Oh I see, caller information is useful.
>
> For compile times: http://llvm-compile-time-tracker.com/?config=O3&stat=instructions&remote=aeubanks.
> The previous version of this patch (perf/npmalways) running a couple passes has some small but measurable overhead on some benchmarks, 0.5%.
> The version of running everything (perf/npmalways2) hugely increases compile times, almost by 50% in one case.

Thanks for doing this! Really good to have this data.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91567/new/

https://reviews.llvm.org/D91567