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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
