Richard Biener <rguent...@suse.de> writes: > On Tue, 2 Feb 2021, Richard Sandiford wrote: > >> Richard Biener <rguent...@suse.de> writes: >> > On January 30, 2021 11:52:20 AM GMT+01:00, Jakub Jelinek >> > <ja...@redhat.com> wrote: >> >>On Sat, Jan 30, 2021 at 11:47:24AM +0100, Richard Biener wrote: >> >>> OK, so I'd prefer we simply unset the flag after processing deferred >> >>rescan. I clearly misread the function to do that. >> >> >> >>This works too, will bootstrap/regtest it now. >> > >> > OK. >> >> FWIW, I'm still not convinced we need to defer the rescan here. >> AIUI, the concern was that the pass introduces uses of something >> and then only later introduces the definition. But that's OK: >> the two things don't have to be added in a set order. >> >> In particular, the normal rescan doesn't propagate the effects >> throughout the cfg; it just updates the list of references in the >> instruction itself and marks the block as dirty for later processing. >> >> The usual reason for deferring rescans is if the instruction can't >> cope with the df_refs changing from under them like that, e.g. >> because they're iterating through a list of df_refs, or because >> they're using df_refs to represent value numbers. It shouldn't >> be a problem for this pass. > > I guess that's correct but doing the scan on the "final" insn > feels much cleaner - given all the confusion it also looks safer > (doing defered scans as before) since I intend to backport this. > But if you feel strongly about this we can of course change it.
I don't feel too strongly about it. It's just that I think the reason we needed two bites at this is because we're trying to do something unusual (have a pass not use DF but nevertheless micromanage the way DF does its updates) instead of trusting the infrastructure to DTRT. Richard