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

[Jan Beulich <jbeulich@suse.com>]

On 17.06.2024 08:49, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, June 14, 2024 8:15 PM
>> To: Binutils <binutils@sourceware.org>
>> Cc: H.J. Lu <hjl.tools@gmail.com>; Cui, Lili <lili.cui@intel.com>
>> Subject: [PATCH 6/6] x86: optimize {,V}PEXTR{D,Q} with immediate of 0
>>
>> 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.

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.

Jan