Fix a dbr_schedule vs. delete_related_insns liveness bug

Richard Sandiford rdsandiford@googlemail.com
Sat Jan 18 10:12:00 GMT 2014


Jeff Law <law@redhat.com> writes:
>> gcc/
>> 	* jump.c (delete_related_insns): Keep (use (insn))s.
>> 	* reorg.c (redundant_insn): Check for barriers too.
> OK.  Any chance you've got a testcase you can add to the suite?  ISTM 
> it's potentially valuable given the plan to remove barriers and the 
> implications that has for reorg.c liveness tracking.

Applied, thanks.  I spent a few hours trying to reduce the testcase
to something that was likely to show the problem reliably, but it looks
like a lot of things have to happen in just the right (or wrong) way.

One of the problems is that if we have:

         barrier
    L1:
         A
         B

and turn it into:

         barrier
    L2:
         B

find_basic_block will not have a basic block for the new label L2
and we won't get a liveness set at all.  So we need a case where we've
cached the find_basic_block result from before the transformation.
This happens in the original testcase because we only introduce the
label during the second reorg pass, but I'm finding it hard to force
cases that can only trigger during the second pass.

The original problem showed up as the tree-prof failures here:

    http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00633.html

but unfortunately that needs a mips64-linux-gnu rather than gdbsim
environment to reproduce.

Thanks,
Richard



More information about the Gcc-patches mailing list