Jakub Jelinek <ja...@redhat.com> writes:
> On Sat, Dec 02, 2023 at 11:04:04AM +0000, Richard Sandiford wrote:
>> I still maintain that so much stuff relies on the lack of false-positive
>> REG_UNUSED notes that (whatever the intention might have been) we need
>> to prevent the false positive. Like Andrew says, any use of single_set
>> is suspect if there's a REG_UNUSED note for something that is in fact used.
>
> The false positive REG_UNUSED in that case comes from
> (insn 15 14 35 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:DI 0 ax [111])
> (reg:DI 1 dx [112]))) "pr112760.c":11:22 12 {*cmpdi_1}
> (expr_list:REG_UNUSED (reg:CCZ 17 flags)
> (nil)))
> (insn 35 15 36 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:DI 0 ax [111])
> (reg:DI 1 dx [112]))) "pr112760.c":11:22 12 {*cmpdi_1}
> (expr_list:REG_DEAD (reg:DI 1 dx [112])
> (expr_list:REG_DEAD (reg:DI 0 ax [111])
> (nil))))
> ...
> use of flags
> Haven't verified what causes the redundant comparison, but postreload cse
> then does:
> 110 if (!count && cselib_redundant_set_p (body))
> 111 {
> 112 if (check_for_inc_dec (insn))
> 113 delete_insn_and_edges (insn);
> 114 /* We're done with this insn. */
> 115 goto done;
> 116 }
> So, we'd in such cases need to look up what instruction was the earlier
> setter and if it has REG_UNUSED note, drop it.
Hmm, OK. I guess it's not as simple as I'd imagined. cselib does have
some code to track which instruction established which equivalence,
but it doesn't currently record what we want, and it would be difficult
to reuse that information here anyway. Something "simple" like a map of
register numbers to instructions, populated only for REG_UNUSED sets,
would be enough, and low overhead. But it's not very natural.
Perhaps DF should maintain a flag to say "the current pass keeps
notes up-to-date", with the assumption being that any pass that
uses the notes problem does that. Then single_set and the
regcprop.cc uses can check that flag.
I don't think it's worth adding the note problem to shrink-wrapping
just for the regcprop code. If we're prepared to take that compile-time
hit, we might as well run a proper (fast) DCE.
Thanks,
Richard
