Re: [PATCH] RISC-V: branch-(not)equals-zero compares against $zero

[Palmer Dabbelt <palmer@rivosinc.com>]

On Thu, 17 Nov 2022 14:44:31 PST (-0800), jeffreyalaw@gmail.com wrote:
>
> On 11/8/22 12:55, Philipp Tomsich wrote:
>> If we are testing a register or a paradoxical subreg (i.e. anything that is not
>> a partial subreg) for equality/non-equality with zero, we can generate a branch
>> that compares against $zero.  This will work for QI, HI, SI and DImode, so we
>> enable this for ANYI.
>>
>> 2020-08-30  gcc/ChangeLog:
>>
>> 	* config/riscv/riscv.md (*branch<mode>_equals_zero): Added pattern.
>
> I've gone back an forth on this a few times.  As you know, I hate
> subregs in the target descriptions and I guess I need to extend that to
> querying if something is a subreg or not rather than just subregs
> appearing in the RTL.
>
>
> Presumably the idea behind rejecting partial subregs is the bits outside
> the partial is unspecified, but that's also going to be true if we're
> looking at a hardreg in QImode (for example) irrespective of it being
> wrapped in a subreg.
>
>
> I don't doubt it works the vast majority of the time, but I haven't been
> able to convince myself it'll work all the time.  How do we ensure that
> the bits outside the mode are zero?  I've been bitten by this kind of
> problem before, and it's safe to say it was exceedingly painful to find.

I don't really understand the middle-end issues here (if there are 
any?), but I'm pretty sure code like this has passed by a few times 
before and we've yet to find a reliable way to optimize these cases.  
There's a bunch of patterns where knowing the XLEN-extension of shorter 
values would let us generate better code, but there's also cases where 
we'd generate worse code by ensure any extension scheme is followed.

Every time I've seen this come up before I've managed to convince myself 
we can't really fix the problem in the backend, though: if we always 
generate extended values in registers then we just push the cost over to 
the other patterns.  The only way I've come up with to handle something 
like this is to push more types into the middle-end so we can track 
these high bits and generate the faster sequences where we know what 
they are.  That seems like a huge mess, though, and every time it comes 
up folks run away ;)

Sorry if that's kind of vague, I usually find a way to break these but 
my box isn't cooperating with GCC builds today so I haven't even gotten 
that far yet...