[PATCH 6/6] x86: optimize {,V}PEXTR{D,Q} with immediate of 0

[Jan Beulich]

On 18.06.2024 05:25, Jiang, Haochen wrote:
>>>> Such are equivalent to simple moves, which are up to 3 bytes shorter to
>>>> encode (and perhaps also cheaper to execute).
>>>
>>> The optimization is problematic. Instead of movd/q, we should optimize to
>>> psrldq, which has lower latency and it is exactly what GCC is doing for 0,1,2,3
>>> in immediate.
>>>
>>> psrldq has only 1 latency, while movd has 3 latency.
>>
>> Wait. While the compiler may use PSRLDQ here, based on knowing
>> assumptions
>> made elsewhere, the assembler can't: The replacement insn must generate the
>> exact same result in the destination register. PSRLDQ with an immediate of
>> 0 (which effectively you're suggesting to use here) doesn't alter the
>> destination register at all, though. When really we want the upper bits of
>> the register cleared.
> 
> pextrd/q also doesn't clear them at all. For vpextrd/q and vpsrldq, they will
> both clear higher bits. So they will be the same.

Wait - your suggestion is even more confusing: The destination of PSRLDQ is
an XMM register, whereas the destination of PEXTR* is a GPR or memory. This
is properly expressed in the constraints in the compiler, but clearly we
can't replace insns like this in the assembler.

>> By implication I question the use of PSRLDQ (should it really happen) when
>> the immediate is 0: If the upper bits are of no interest, a yet simpler
>> MOVDQ{A,U} could then be used. Or, if source and destination match, no insn
>> would need emitting at all.
>>
>>> Also, I suppose the optimization related to latency should not be done in
>>> assembler.
>>
>> Why? We have -O, -O1, and -O2 alongside -Os for a reason.
> 
> I am quite conservative on the optimization in assembler. If we are also going to
> optimize those hand-written code, the optimization could work.
> 
> However, when they hand write some code, are we supposed to change them?

Well, if we aren't to, people simply don't pass -O.

> For -Os, we could give them all the optimizations we have, but for -O, I am not
> that sure.
> 
> And I suppose we might add too much burden for the assembler if we are going
> to add too much optimizations related to latency. It will become another compiler.
> Are we supposed to copy all the optimizations from compiler?

Probably not all (and many aren't the the insn level anyway, nor do we - so
far at least - optimize for latency/throughput at the expense of code size).
But yes - this specific aspect is why I keep raising questions on what
optimizations are worth it vs where we'd better leave code alone.

Jan

> IMO, optimization to
> codesize is ok, but for latency, I am a little concerned.
> 
> Thx,
> Haochen
> 
>>
>> Jan