[PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Jeff Law]

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  <segher@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