Richard Biener <rguent...@suse.de> writes:
> 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 ...
Yeah, but the updates are incremental. I think in many cases we'll
be doing the same work, just slightly earlier than before. E.g. in the
example above, something is going to recalculate df_get_live_out
eventually. And splits don't normally change liveness at block
boundaries (unless they're buggy).
So I think the question is: can we see a noticeable increase in compile
time if we do make the split passes use DF? This should be measured on
a release build since I don't think the extra checking overhead should
count.
Thanks,
Richard
