[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Roman Zhuykov from comment #6)
> First, I want here to mention that Richard have recently discussed
> partitioning in mailing list with Segher, starting from
> https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html
> 
> > I'll run some cross-testing to check how it works for now.
> Second, those tests have finished and there is nothing to say about the
> results. From correctness aspect everything looks fine.  But I haven't tried
> to look at each example where it prevents/allows loops to be scheduled, and
> know nothing about performance impact.
> 
> (In reply to rsandifo@gcc.gnu.org from comment #4)
> > Yeah, it ought to be better to do mode switching first.  But I think
> > the more important ones are:
> >
> >        NEXT_PASS (pass_split_all_insns);
> >        NEXT_PASS (pass_lower_subreg3);
> >
> > Scheduling should happen on the split form of insns rather than the
> > unsplit form.  lower_subreg should also improve "schedulability".
> Agreed, so it would be much better to fix the issue conservatively without
> moving the pass.

As of pass ordering partitioning needs to run before RA but I don't see
why it necessarily needs to run that early.  Well, it works on CFG layout
mode and it's the "last" pass before we go out of CFG layout - but obviously
SMS goes back into so we could do the very same dance for partitioning
and only schedule it after SMS (or even later).

The whole complication arises from the direct CFG edges that are
implemented with indirect jumps and which we cannot easily redirect.
A more high-level representation of those "direct jumps" would make
redirection possible again (at the expense of micro-optimizing the
reg set + indirect jump between partitioning and the point we
expose the operation).  The only thing we need is the RA giving us
a scratch register we can use.  Maybe we can have a special named
pattern for those jumps allocating an extra scratch and have targets
either split them after reload into true indirect jumps or leave them
in place all the way to asm output.  So they'd appear as simple_jump_p
for a much longer time?

Currently we have

(insn 577 350 578 27 (set (reg:DI 309)
        (high:DI (label_ref:DI 220))) "pr71550.c":19:20 -1
     (insn_list:REG_LABEL_OPERAND 220 (nil)))
(insn 578 577 579 27 (set (reg:DI 308)
        (lo_sum:DI (reg:DI 309)
            (label_ref:DI 220))) "pr71550.c":19:20 -1
     (insn_list:REG_LABEL_OPERAND 220 (expr_list:REG_EQUAL (label_ref:DI 220)
            (nil))))
(jump_insn/j 579 578 220 27 (set (pc)
        (reg:DI 308)) "pr71550.c":19:20 -1
     (nil)

not sure if jump_insns can have extra operands for the scratch but
we want part of the jump to be like

(jump_insn/j 579 578 220 27 (set (pc)
        (label_ref:DI 220)) "pr71550.c":19:20 -1
     (nil)

but also mention (reg:DI 309) as scratch.

Ideas?  I guess doing

(jump_insn/j 579 578 220 27 [
  (set (pc) (label_ref:DI 220))
  (clobber (reg:DI 309))])

might work?  The pattern of the jump insn woudl be a parallel though
so not match simplejump_p.  There's also JUMP_LABEL, not sure if that's
usable.  There's condjump_in_parallel_p so we could add
simplejump_in_parallel_p as well and use that in CFG manipulation.

This woudl of course need support from targets but where partitioning
decides it needs to emit indirect jumps it could say that it needs
such target support or otherwise refuse to operate.  Currently
we look at HAS_LONG_COND_BRANCH / HAS_LONG_UNCOND_BRANCH where
only failure in the latter needs indirect jumps using "indirect_jump".
So we'd add sth like

(define_insn "crossing_jump"
  [(set (pc) (label_ref (match_operand 0 "" ""))
   (clobber (match_scratch:DI 1))]
  ""
  "br\\t%1"
  [(set_attr "type" "branch")]
)

with the assembly part adjusted accordingly (the move is missing).  As said
a late splitter may be the best approach (but that's up to the target).

And partitioning would require either HAS_LONG_UNCOND_BRANCH or
targetm.have_crossing_jump and we'd arrange for CFG manipulation to
handle this form.
Oh, and while these issues can trigger in a way appearing as P1 regression
they of course really are not new issues.  So yeah, not really P1.