On Tue, 16 Feb 2021, Richard Sandiford wrote:
> Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > Hi!
> >
> > The following testcase started ICEing with my recent changes to enable
> > split4 after sel-sched, but it seems the bug is more general.
> > Some of the i386 splitter condition functions use and rely on df, but
> > the split passes don't really df_analyze/df_finish_pass, so the DF info
> > may be stale or not computed at all - the particular ICE is because
> > there is a new bb and df_get_live_out (bb) returns NULL on it as the
> > live or lr problem has not been computed yet.
> >
> > The following patch makes it possible to call df_analyze during split
> > on demand (on the first occassion where it is needed) and changes the
> > i386 backend to do so. I needed a target hook that signifies the end
> > of the split pass so that the backend can reset its flag and return
> > the todo flags (TODO_df_finish in this case) to the caller if needed.
>
> This seems like it could be a recurring source of bugs. Not everything
> is necessarily going to be aware that it's using DF information.
> And even if the code is aware, it'll be easy to forget that this
> extra step is necessary.
>
> The bug only showed up here because the failure was noisy. In other
> situations, using out-of-date DF information could compile but lead to
> wrong code.
>
> If we want it to be valid for define_splits to use DF information,
> I think we should just make the split passes use DF unconditionally.
On IRC I was suggesting to assert that the problems are clean in
df_get_live_out, via checking df_{lr,live}->solutions_dirty. That would
trip on them. I guess no backend can rely on anything else than
df-scan which should be up-to-date or df_live/lr, and without extra
dances it would use df_get_live_out to choose from the two.
Just to get an idea whether it's worth doing the extra df_analyze.
Since we have possibly 5 split passes it's a lot of churn for things
like that WRF ltrans unit that already spends 40% of its time in DF ...
Richard.
> Thanks,
> Richard
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
