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
