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