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. Thanks, Richard.
