This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix a dbr_schedule vs. delete_related_insns liveness bug


On 01/18/14 03:12, Richard Sandiford wrote:
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 for taking the time to try and pull something together. I've certainly got no objections to this going forward without a regression test.

Thanks,
Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]