Hi Jeff, On Sun, 2025-11-30 at 15:33 -0700, Jeff Law wrote: > > We don't bother with the transformation when the XOR is flipping a bit > known to be zero (ie, a high bit of the result of the right shift or a > low bit on the result of the left shift). For those cases we already > figure out that the XOR is just an IOR and the right things already > "just happen". > > This triggered some code generation changes on the SH (not surprising > because this BZ was derived from an older SH BZ). It doesn't seem to > significantly improve the SH code, though it does turn a cmp/pz + rotate > through carry with a rotate + xor with immediate. That may be a > latency win on the SH, I really don't know. >
Thanks for keeping SH in mind. On SH the replacement "rotate + xor with immediate" is not a win, because: - both insns are of EX type on classic SH4 (no parallel execution) - xor with immediate puts additional register pressure on R0 Since cmp/pz is of MT type on classic SH4 it is more likely to be executed in parallel with another insn. No idea really how to express these kind of machine / ISA specifics for the GIMPLE layers. The only way I can think of is to keep updating the insns patterns and hacks in the .md file. The change of the insn sequence on SH is a regression. PR 59533 is explicitly about "missed cmp/pz opportunity". Please drop the changes to gcc/testsuite/gcc.target/sh/pr59533-1.c, so that it's clear that something's not the way it was supposed to be. Best regards, Oleg Endo
