[PATCH] x86: support -Ofast

[Jan Beulich]

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

Jan