[PATCH] x86: support -Ofast

[H.J. Lu]

On Fri, Sep 4, 2026 at 3:01 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 04.09.2026 08:26, H.J. Lu wrote:
> > On Tue, Sep 1, 2026 at 6:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 28.08.2026 22:48, H.J. Lu wrote:
> >>> On Fri, Aug 28, 2026 at 8:02 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 28.08.2026 11:51, H.J. Lu wrote:
> >>>>> On Fri, Aug 28, 2026 at 4:39 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> ... in analogy to gcc's option of the same name: It relaxes constraints
> >>>>>> on (the lack of) commutativity of V{ADD,MAX,MIN,MUL}{P,S}{S,D}. They're
> >>>>>> not fully commutative solely because of their NaN treatment. If the
> >>>>>> programmer indicates that's benign to them, we can apply the VEX3->VEX2
> >>>>>> encoding transformation for these AVX insns as well.
> >>>>>> ---
> >>>>>> If we wanted to also use this to control optimization of NOP-like insns
> >>>>>> (e.g. the XCHG -> MOV one), the variable would want renaming. Question is:
> >>>>>> _Do_ we (perhaps) want that?
> >>>>
> >>>> With this I was trying to offer a compromise on the earlier discussion
> >>>> regarding the XCHG -> MOV optimization. It was certainly my expectation
> >>>> that ...
> >>>>
> >>>>>> --- a/gas/doc/c-i386.texi
> >>>>>> +++ b/gas/doc/c-i386.texi
> >>>>>> @@ -624,7 +624,9 @@ only and AMD64 ISAs.
> >>>>>>  @cindex @samp{-O2} option, x86-64
> >>>>>>  @cindex @samp{-Os} option, i386
> >>>>>>  @cindex @samp{-Os} option, x86-64
> >>>>>> -@item -O0 | -O | -O1 | -O2 | -Os
> >>>>>> +@cindex @samp{-Ofast} option, i386
> >>>>>> +@cindex @samp{-Ofast} option, x86-64
> >>>>>> +@item -O0 | -O | -O1 | -O2 | -Os | -Ofast
> >>>>>>  Optimize instruction encoding with smaller instruction size.  @samp{-O}
> >>>>>>  and @samp{-O1} encode 64-bit register load instructions with 64-bit
> >>>>>>  immediate as 32-bit register load instructions with 31-bit or 32-bits
> >>>>>> @@ -648,6 +650,12 @@ same (register) operand specified twice
> >>>>>>  and 64-bit register tests with immediate as 8-bit register test with
> >>>>>>  immediate.  @samp{-O0} turns off this optimization.
> >>>>>>
> >>>>>> +@samp{-Ofast} is separate from other optimization options.  Its use
> >>>>>> +indicates to the assembler that not entirely correct optimizations may
> >>>>>> +be applied, e.g. assuming the absence of NaN-s.  See the compiler's
> >>>>>
> >>>>> I am against such options which may introduce incorrect behavior.
> >>>>> Programmers should use -Ofast compiler option or appropriate
> >>>>> assembler instructions.
> >>>>
> >>>> ... in case of objections a fair attempt would be made to suggest some
> >>>> alternative approach there, which respects earlier arguments.
> >>>>
> >>>> Independent of that I don't quite understand your argument. Demanding
> >>>> programmers to use "appropriate assembler instructions" can be extended
> >>>> to all -O handling that we have. Already in the earlier discussion I
> >>>
> >>> But they don't change program behavior.
> >>
> >> This response I can see apply to the optimization aspect (hence why
> >> -Ofast is proposed to be separate from other -O...), but not to your
> >> earlier "should use ... appropriate assembler instructions", which
> >> this part of my reply was about. Why is changing program behavior
> >> relevant here? As we've seen with the XCHG->MOV optimization, program
> >> behavior can be changed by any optimization: That'll always be the
> >> case when specific encodings are expected. Hence, as said, this and
> >> your earlier argument would extend to all -O handling we have.
> >
> > What -Ofast implies may mislead users.
>
> That's what we have documentation for.
>
> >>>> did ask whether you're suggesting to rip out all optimizations again.
> >>>> Please may I ask that your argumentation include not only your original
> >>>> pov (optimizations are there to post-process compiler output), but also
> >>>> the other perspective of it being useful on (often poorly) hand-written
> >>>> assembly? (I don't want to repeat arguments already given, but my
> >>>> perspective on post-processing compiler output hasn't changed.)
> >>>
> >>> I can live with something like -Oexperimental and warn users that
> >>> they must know what they are doing.
> >>
> >> And how does "experimental" describe the properties of these
> >> optimizations? Also, users using -O must know what they're doing,
> >> no matter what. Use of this group of options makes certain assertions
> >> about the program's expectations (i.e., as per above, no assumptions
> >> on specific encodings used).
> >>
> >> It feels like you simply do not want to accept that introduction of
> >> some arbitrary optimization can in principle break software which
> >
> > Please don't put words in my mouth.   I just don't think -Ofast is
> > appropriate.   With -Oexperimental, you can do much more.
>
> "experimental" to me means what's covered by it will, at some point,
> become non-experimental. That isn't, aiui, the plan here though.

Use a different name, not -Ofast.

> And yes, to cover NOP pattern conversions, -Ofast may not be optimal
> (no matter that "fast" describes the purpose well, hence why I
> suggested re-using it). Yet then what is needed is a clearly better
> name, which -Oexperimental (as per above, including my earlier reply)
> isn't.
>
> Jan
>
> >> isn't really meant to have "canonical" encodings exchanged by "non-
> >> canonical" ones. That's true for every optimization, yet you continue
> >> to try to tie this to specific reports of problems. How do you know
> >> others didn't run into problems as well, simply doing the expected
> >> thing: Either adjust their assumptions, or avoid the use of
> >> optimization? The problem I'm facing here is: How can I get you to
> >> understand (and accept) this pretty basic fact?
> >>
> >
> >
> >
>


-- 
H.J.