Re: [PATCH] x86: support -Ofast

On 28.08.2026 22:48, H.J. Lu wrote:
> 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.

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.

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

Jan