[PATCH] x86: support -Ofast

[H.J. Lu]

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.

> >> 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.

> 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.