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.
The reason I'm interested is that AArch64 makes pretty extensive use
of match_dup for this purpose. E.g.:
(define_insn "aarch64_<su>abd<mode><vczle><vczbe>"
[(set (match_operand:VDQ_BHSI 0 "register_operand" "=w")
(minus:VDQ_BHSI
(USMAX:VDQ_BHSI
(match_operand:VDQ_BHSI 1 "register_operand" "w")
(match_operand:VDQ_BHSI 2 "register_operand" "w"))
(<max_opp>:VDQ_BHSI
(match_dup 1)
(match_dup 2))))]
So if this isn't working correctly for subregs (or for anythine else),
then I'd be keen to do something about it :)
I don't want to labour the point though.
Thanks,
Richard
