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

Fri Nov 12 15:34:15 PST 2021

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)

On Fri, Nov 12, 2021 at 3:08 PM Johannes Doerfert via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On 11/12/21 16:17, paul.robinson at sony.com wrote:
> >
> >> -----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.
>
> It's complicated yes, but we got it wrong already. You said so yourself
> and any `no-ipa` discussion/bug will also attest to that. The idea that
> *not* changing anything anymore is therefore somewhat counter-intuitive
> to me. If we would actually sit down to define what the interactions are
> we could fix existing problems and make progress. However, using the
> `no-ipa` discussions again as example, w/o a new attribute there is no way
> to make everyone happy. The problem is not that we "add too much", the
> problem (often) is that we do overload what we have rather than
> differentiate properly what we want. (Why we do that is a different
> question.)
>
> `optnone`/`noinline` means different things to different people,
> as did `derferenceable` and other attributes. The solution to these
> problems
> was, and will continue to be, differentiation through new
> attributes/options.
>
> Long story short, it's not the number of attributes/options that is the
> problem
> but nailing down their semantics and interplay. That is not to say we get
> it
> right by adding more, but history shows problems are solved through new
> ones if
> the problems of existing ones are taken into account during their
> definition.
>
> ~ Johannes
>
>
>
> > --paulr
> >
> _______________________________________________
> 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/0f52562b/attachment.html>