[PATCH] split, i386: Fix up df uses in i386 splitters [PR99104]

Richard Sandiford richard.sandiford@arm.com
Tue Feb 16 08:37:33 GMT 2021


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.

Thanks,
Richard


More information about the Gcc-patches mailing list