Re: [PATCH] x86: support -Ofast

On Fri, Aug 28, 2026 at 8:02 PM Jan Beulich <[email protected]> wrote:
>
> On 28.08.2026 11:51, H.J. Lu wrote:
> > On Fri, Aug 28, 2026 at 4:39 PM Jan Beulich <[email protected]> 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.

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


-- 
H.J.