Fix a dbr_schedule vs. delete_related_insns liveness bug
Sat Jan 18 10:12:00 GMT 2014
Jeff Law <firstname.lastname@example.org> writes:
>> * 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:
and turn it into:
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:
but unfortunately that needs a mips64-linux-gnu rather than gdbsim
environment to reproduce.
More information about the Gcc-patches