This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix a dbr_schedule vs. delete_related_insns liveness bug
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 18 Jan 2014 10:12:42 +0000
- Subject: Re: Fix a dbr_schedule vs. delete_related_insns liveness bug
- Authentication-results: sourceware.org; auth=none
- References: <87eh49nizr dot fsf at talisman dot default> <52D6FE2D dot 7060709 at redhat dot com>
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