[llvm-dev] [RFC] Removing optimization size level from LLVM and relying on minsize/optsize

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 12 18:01:45 PST 2021


With respect to Os/Oz, it seems to me that what is controlled by the
attribute can largely be orthogonal to the actual passes that are executed.

In this sense the attributes (optnone, minsize, optsize) conveys
"optimizations hints", which can largely be orthogonal to how the pass
pipeline is set up.
Of course, with this view the "minsize" attribute shouldn't have much
effect when setting up an O0 kind of pass pipeline.

On the other hand, I have a hard time seeing O1/O2/O3 encoded in the IR: I
see these very much as pass pipeline setup. Encoding this in the IR would
also be hard to reconcile with how we've been doing LTO. But I'd be
interested to see a more detailed RFC if anyone wanted to look into this.

-- 
Mehdi

On Fri, Nov 12, 2021 at 12:04 PM 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, 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?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211112/87742436/attachment.html>


More information about the llvm-dev mailing list