<div dir="ltr">How would PassBuilderPipelines.cpp getInlineParamsFromOptLevel be implemented - note that the params affect a module-wide policy. Or would there be module-wide attributes and a priority scheme? (I'm trying to understand the full proposal)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 12, 2021 at 3:08 PM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 11/12/21 16:17, <a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a> wrote:<br>
><br>
>> -----Original Message-----<br>
>> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Johannes<br>
>> Doerfert via llvm-dev<br>
>> Sent: Friday, November 12, 2021 4:31 PM<br>
>> To: Matt Arsenault <<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>>; Arthur Eubanks<br>
>> <<a href="mailto:aeubanks@google.com" target="_blank">aeubanks@google.com</a>><br>
>> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Tarindu Jayatilaka<br>
>> <<a href="mailto:tarindujayatilaka@gmail.com" target="_blank">tarindujayatilaka@gmail.com</a>><br>
>> Subject: Re: [llvm-dev] [RFC] Removing optimization size level from LLVM<br>
>> and relying on minsize/optsize<br>
>><br>
>><br>
>> On 11/12/21 14:09, Matt Arsenault via llvm-dev wrote:<br>
>>>> On Nov 12, 2021, at 15:03, Arthur Eubanks via llvm-dev <llvm-<br>
>> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>> wrote:<br>
>>>> Currently in the LLVM IR optimization pipelines we pass around an<br>
>> OptimizationLevel, which consists of a speedup level and a size level<br>
>> (e.g. -O1 is {1, 0}, -Oz is {2, 2}). We use the size level to turn on/off<br>
>> some passes and also to determine inliner thresholds.<br>
>>>> When attempting to add support for -Os/-Oz in<br>
>> <a href="https://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGBv" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGBv</a><br>
>> 3RvKRSx!p0ynTSMsF1gDjsDYRsLyrJBMVYJVoxDbIGcbR3O9ZFWpknnQtWFkW40vUtzP1oWu_Q<br>
>> $<br>
>> <<a href="https://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGB" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://reviews.llvm.org/D113738__;!!JmoZiZGB</a><br>
>> v3RvKRSx!p0ynTSMsF1gDjsDYRsLyrJBMVYJVoxDbIGcbR3O9ZFWpknnQtWFkW40vUtzP1oWu_<br>
>> Q$ >, I got some pushback saying that we should be relying on the function<br>
>> attributes minsize and optsize. The logical extension of that is to<br>
>> completely remove the size level from OptimizationLevel and rely on<br>
>> frontends to set minsize/optsize for -Os/-Oz. Passes that are disabled<br>
>> with -Os/-Oz can check those attributes instead.<br>
>>>> There are some tests (e.g. inline-optsize.ll) that test that if we have<br>
>> optsize and -Oz, the lower inlining threshold (-Oz in this case) wins, but<br>
>> perhaps we can revisit that and calculate inline thresholds purely based<br>
>> on the function attributes.<br>
>>>> Any thoughts?<br>
>>>><br>
>>> I do not believe in encoding optimization levels in the IR. The<br>
>> optimization level is an option for the machinery of the compiler, and not<br>
>> part of the semantics of the program.<br>
>><br>
>> While I agree it is not semantics, we already encode similar things,<br>
>> e.g. related to toolchains and architectures, optnone, ... in different<br>
>> places of the IR.<br>
>> Maybe I'm missing why having such information in the IR is inherently bad.<br>
>><br>
>> I say this because I very much like to encode all optimizations levels<br>
>> in IR, incl. O0/1/2/3/z/s/..., such that we can select the level per<br>
>> function rather than per file.<br>
>> We have a prototype for that incl. some pass manager work but it's not<br>
>> ready for prime time yet (IIRC).<br>
> We defined "optnone" in order to allow selectively disabling<br>
> optimization at the source level; this is very useful to users.<br>
> You can argue about whether it conveys "IR semantics" but it<br>
> certainly reflects a choice made by the programmer, and to implement<br>
> that choice it needed to be recorded in the IR.  We don't have any<br>
> other mechanism for conveying that kind of information to LLVM.<br>
><br>
> "optnone" was then leveraged to allow compiling "-flto -O0" on<br>
> some modules to be preserved through the LTO stage, which is why<br>
> Clang puts optnone on all functions at -O0.  Chandler was quite<br>
> clear at the time that "no optimization" was different in kind<br>
> from "some level of optimization" and resisted encoding levels<br>
> other than optnone into the IR (although I believe optsize/minsize<br>
> predate optnone).<br>
><br>
> Encoding these things in IR means defining rules for how they<br>
> interact when IPOs find functions with differing optimization<br>
> controls.  We punted on this for optnone, instead defining a rule<br>
> that said optnone functions had to be marked noinline, so the<br>
> inliner didn't need to learn a special rule about optnone functions.<br>
> I see things crossing the lists about how floating-point controls<br>
> get interprocedural behavior wrong all the time.  My takeaway is:<br>
>      It's complicated, and we don't want to go there.<br>
> I'd be very hesitant to start throwing lots more combinations into<br>
> the mix.<br>
<br>
It's complicated yes, but we got it wrong already. You said so yourself<br>
and any `no-ipa` discussion/bug will also attest to that. The idea that<br>
*not* changing anything anymore is therefore somewhat counter-intuitive<br>
to me. If we would actually sit down to define what the interactions are<br>
we could fix existing problems and make progress. However, using the<br>
`no-ipa` discussions again as example, w/o a new attribute there is no way<br>
to make everyone happy. The problem is not that we "add too much", the<br>
problem (often) is that we do overload what we have rather than<br>
differentiate properly what we want. (Why we do that is a different <br>
question.)<br>
<br>
`optnone`/`noinline` means different things to different people,<br>
as did `derferenceable` and other attributes. The solution to these problems<br>
was, and will continue to be, differentiation through new <br>
attributes/options.<br>
<br>
Long story short, it's not the number of attributes/options that is the <br>
problem<br>
but nailing down their semantics and interplay. That is not to say we get it<br>
right by adding more, but history shows problems are solved through new <br>
ones if<br>
the problems of existing ones are taken into account during their <br>
definition.<br>
<br>
~ Johannes<br>
<br>
<br>
<br>
> --paulr<br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>