[PATCH] i386, df: Fix up gcc.c-torture/compile/20051216-1.c -O1 -march=cascadelake

[Richard Sandiford]

Richard Biener <rguenther@suse.de> writes:
> On Tue, 2 Feb 2021, Richard Sandiford wrote:
>
>> Richard Biener <rguenther@suse.de> writes:
>> > On January 30, 2021 11:52:20 AM GMT+01:00, Jakub Jelinek <jakub@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