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

[David Blaikie via llvm-dev]

(sorry, haven't read all the replies)

I think there was a fair bit of discussion on this when the optnone and
minsize attributes were added way-back-when - Chandler at least expressed a
pretty firm opinion that these more "fundamental" requests that are
currently attributes were distinct from -O1/2/3 - like noinline, there's
some specific property we want from the code with those attributes that's
hardest to describe with O1/2/3 which are a vague sliding scale of
size/perf tradeoffs.

But for things we already have attributes for - yeah, naively (ie: take my
opinion with lots of salt) it seems reasonable to have them be the only way
to convey that information. (wonder if/how bad it'd be to do that with
-O0/optnone... maybe not much value in it? Not sure - could make LTO and
non-LTO more similar maybe - would exercise the "is optnone respected even
in a single file" more frequently)

On Fri, Nov 12, 2021 at 6:02 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
> _______________________________________________
> 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/2e1c4827/attachment.html>