On 9/7/2022 6:45 AM, Richard Biener via Gcc-patches wrote:
On Wed, Sep 7, 2022 at 2:20 PM Robin Dapp <rd...@linux.ibm.com> wrote:
The question is really whether xor or sub is "better" statically. I can't
think of any reasons. On s390, why does xor end up "better"?
There is an xor with immediate (as opposed to no "subtract from
immediate") which saves an instruction, usually. On x86, I think the
usual argument for xor is that it's shorter (if flags etc. are not needed).
It's not that I don't want to implement it in the backend, just that I
understood the original PR in a way that it would make sense to have
this conversion available for more targets. If there are too many
confounding factors that prevent this situation from being statically
costed properly, then sure, not much use in implementing it generally.
Do we have evidence that targets properly cost XOR vs SUB RTXen?
Probably not. And I have vague memories of some targets not having xor
with immediate, but which did have more expressive sub instructions (so
the opposite of the situation on s390).
Checking costs seems like a very sensible thing to do though and if
targets need adjustment, then we can cope.
It might actually be a reload optimization - when the constant is
available in a register use 'sub', when it needs to be reloaded
use 'xor'?
Perhaps. The question is finding out of the constant is actually
available in a register. We don't do a particularly good job at that.
That said, I wonder if the fallout of changing some SUB to XOR
is bigger than the benefit when we do it early (missed combines, etc.)?
Quite possibly -- though I doubt it matters in practice.
jeff
