llvm dev - Nov 2021 - [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

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
Johannes
> Doerfert via llvm-dev
> Sent: Friday, November 12, 2021 4:31 PM
> To: Matt Arsenault <arsenm2 at gmail.com>; Arthur Eubanks
> <aeubanks at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Tarindu Jayatilaka
> <tarindujayatilaka at gmail.com>
> Subject: Re: [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://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGBv
> 3RvKRSx!p0ynTSMsF1gDjsDYRsLyrJBMVYJVoxDbIGcbR3O9ZFWpknnQtWFkW40vUtzP1oWu_Q
> $
>
<https://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGB
> v3RvKRSx!p0ynTSMsF1gDjsDYRsLyrJBMVYJVoxDbIGcbR3O9ZFWpknnQtWFkW40vUtzP1oWu_
> Q$ >, 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).
We defined "optnone" in order to allow selectively disabling 
optimization at the source level; this is very useful to users.  
You can argue about whether it conveys "IR semantics" but it 
certainly reflects a choice made by the programmer, and to implement 
that choice it needed to be recorded in the IR.  We don't have any
other mechanism for conveying that kind of information to LLVM.

"optnone" was then leveraged to allow compiling "-flto -O0"
on
some modules to be preserved through the LTO stage, which is why 
Clang puts optnone on all functions at -O0.  Chandler was quite 
clear at the time that "no optimization" was different in kind 
from "some level of optimization" and resisted encoding levels 
other than optnone into the IR (although I believe optsize/minsize 
predate optnone).

Encoding these things in IR means defining rules for how they 
interact when IPOs find functions with differing optimization 
controls.  We punted on this for optnone, instead defining a rule 
that said optnone functions had to be marked noinline, so the 
inliner didn't need to learn a special rule about optnone functions.  
I see things crossing the lists about how floating-point controls 
get interprocedural behavior wrong all the time.  My takeaway is:
    It's complicated, and we don't want to go there.
I'd be very hesitant to start throwing lots more combinations into 
the mix.

--paulr