On 01/14/2017 10:55 AM, Segher Boessenkool wrote:
If a jump always falls through but that cannot be optimised away, like
is the case with the PowerPC bdnz insn if its jump target is the same as
the fallthrough, sched gets confused if it schedules some instructions
from before that jump instruction to behind it: it splits the
fallthrough branch, but the jump target isn't updated, and things fall
apart as in the PR. This patch fixes it.
The second patch fragment makes -fsched-verbose=N work for N>=4; the
currently scheduled fragment can now contain a label. Everything else
seems to work fine with that.
Tested on powerpc*-linux (with the testcase Alan checked in earlier
today); also bootstrapped on powerpc64-linux. Is this okay for trunk?
Segher
2017-01-14 Segher Boessenkool <seg...@kernel.crashing.org>
PR target/72749
* cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
fallthrough.
* haifa-sched.c (dump_insn_stream): Don't crash if there is a label
in the currently scheduled RTL fragment.
So presumably the semantics in this case can only mean one thing -- both
the fallthru and the jump have to go to the same place after splitting.
Right? ISTM that ought to be documented in rtl_split_edge somewhere.
In this case is the edge a fallthru or branch edge?
And, no we don't make any guarantee about degenerate jumps -- a jump
with a side effect in particular can easily survive. I wouldn't be
surprised if there's various bugs lurking for cases where we have a
degenerate jump like that. It's just not common enough to have been
heavily exercised.
Patch with PATTERN fix is OK.
jeff
