Matt Arsenault via llvm-dev
2021-Nov-12 20:09 UTC
[llvm-dev] [RFC] Removing optimization size level from LLVM and relying on minsize/optsize
> On Nov 12, 2021, at 15:03, Arthur Eubanks via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Currently in the LLVM IR optimization pipelines we pass around an OptimizationLevel, which consists of a speedup level and a size level (e.g. -O1 is {1, 0}, -Oz is {2, 2}). We use the size level to turn on/off some passes and also to determine inliner thresholds. > > When attempting to add support for -Os/-Oz in https://reviews.llvm.org/D113738 <https://reviews.llvm.org/D113738>, I got some pushback saying that we should be relying on the function attributes minsize and optsize. The logical extension of that is to completely remove the size level from OptimizationLevel and rely on frontends to set minsize/optsize for -Os/-Oz. Passes that are disabled with -Os/-Oz can check those attributes instead. > > There are some tests (e.g. inline-optsize.ll) that test that if we have optsize and -Oz, the lower inlining threshold (-Oz in this case) wins, but perhaps we can revisit that and calculate inline thresholds purely based on the function attributes. > > Any thoughts? >I do not believe in encoding optimization levels in the IR. The optimization level is an option for the machinery of the compiler, and not part of the semantics of the program. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211112/6c0515a8/attachment.html>
Johannes Doerfert via llvm-dev
2021-Nov-12 21:31 UTC
[llvm-dev] [RFC] Removing optimization size level from LLVM and relying on minsize/optsize
On 11/12/21 14:09, Matt Arsenault via llvm-dev wrote:> >> On Nov 12, 2021, at 15:03, Arthur Eubanks via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Currently in the LLVM IR optimization pipelines we pass around an OptimizationLevel, which consists of a speedup level and a size level (e.g. -O1 is {1, 0}, -Oz is {2, 2}). We use the size level to turn on/off some passes and also to determine inliner thresholds. >> >> When attempting to add support for -Os/-Oz in https://reviews.llvm.org/D113738 <https://reviews.llvm.org/D113738>, I got some pushback saying that we should be relying on the function attributes minsize and optsize. The logical extension of that is to completely remove the size level from OptimizationLevel and rely on frontends to set minsize/optsize for -Os/-Oz. Passes that are disabled with -Os/-Oz can check those attributes instead. >> >> There are some tests (e.g. inline-optsize.ll) that test that if we have optsize and -Oz, the lower inlining threshold (-Oz in this case) wins, but perhaps we can revisit that and calculate inline thresholds purely based on the function attributes. >> >> Any thoughts? >> > I do not believe in encoding optimization levels in the IR. The optimization level is an option for the machinery of the compiler, and not part of the semantics of the program.While I agree it is not semantics, we already encode similar things, e.g. related to toolchains and architectures, optnone, ... in different places of the IR. Maybe I'm missing why having such information in the IR is inherently bad. I say this because I very much like to encode all optimizations levels in IR, incl. O0/1/2/3/z/s/..., such that we can select the level per function rather than per file. We have a prototype for that incl. some pass manager work but it's not ready for prime time yet (IIRC). ~ Johannes> -Matt > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev