Re: [PATCH] expand: Convert cst - x into cst xor x.

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/7/2022 6:45 AM, Richard Biener via Gcc-patches wrote:
> On Wed, Sep 7, 2022 at 2:20 PM Robin Dapp <rdapp@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