Re: [PATCH 2/5] [RISC-V] Generate Zicond instruction for basic semantics

[Jeff Law <jeffreyalaw@gmail.com>]

On 8/2/23 04:05, Richard Sandiford wrote:
> Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>> On 8/1/23 05:18, Richard Sandiford wrote:
>>>
>>> Where were you seeing the requirement for pointer equality?  genrecog.cc
>>> at least uses rtx_equal_p, and I think it has to.  E.g. some patterns
>>> use (match_dup ...) to match output and input mems, and mem rtxes
>>> shouldn't be shared.
>> It's a general concern due to the way we handle transforming pseudos
>> into hard registers after allocation is complete.   We can end up with
>> two REG expressions that will compare equal according to rtx_equal_p,
>> but which are not pointer equal.
> 
> But isn't that OK?  I don't think there's a requirement for match_dup
> pointer equality either before or after RA.  Or at least, there
> shouldn't be.  If something happens to rely on pointer equality
> for match_dups then I think we should fix it.


> 
> So IMO, like you said originally, match_dup would be the right way to
> handle this kind of pattern.
I'd assumed that match_dup required pointer equality.  If it doesn't, 
then great, we can adjust the pattern to use match_dup.  I'm about to 
submit some bits to simplify/correct a bit of zicond.md, then I can do 
some testing with match_dup in place now that things seem to be more 
stable on the code generation correctness side.


> 
> I don't want to labour the point though.
No worries about that on my end!  I probably don't say it enough, but 
when you raise an issue, it's worth the time to make sure I understand 
your point thoroughly.

In this case I'd assumed that match_dup relied on pointer equality which 
doesn't seem to be the case.  30+ years into this codebase and I'm still 
learning new stuff!

Jeff