This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to fix unintentional(?) pessimisation in dbr_schedule
Richard Henderson <rth@redhat.com> writes:
> On Mon, Apr 05, 2004 at 11:13:44PM +0100, Richard Sandiford wrote:
>> [A] if always_true()
>> / \
>> [B] x = foo() eventually_abort_but_not_marked_noreturn () [C]
>> \ /
>> [D] blah(x)
> [...]
>> (2) A: if always_true () goto B else goto PC
>> C: eventually_abort_but_not_marked_noreturn ()
>> goto D
>> barrier
>> B: x = foo ()
>> D: blah(x)
> [...]
>> Which statement and rtl expansion will get the wrong liveness
>> info with IOR? Assuming that the cfg code correctly marks
>> "x" as live on entry to and exit from A and C, I think both
>> techniques will correctly detect whether "x" is live.
>
> Why should it? Recall that this is after reload, and x might
> live in a call-clobbered register. So it's live between foo
> and blah.
Right. But when doing the scan-forward thing from A or C:
(a) dbr_schedule starts off with S, the registers live at D. It will
correctly detect that S includes "x" because it scans from the
previous barrier and notices the assignment in B.
(b) It then adds all registers that are used before being set on
the path to "goto D". It doesn't remove anything, so the final
estimate is a superset of S.
So AIUI, in the case you quote above, the scan-forward technique
will pessimistically mark "x" as live in both A and C.
Richard