Bernd Schmidt <ber...@codesourcery.com> writes: > Because of this problem, I've chosen a different model for this patch. > Before calling the final sched_ebb pass, the port must split jump insns > (or anything that should have delay slots) into two separate insns, a > real insn and a shadow. As an example, > > (jump_insn (set (pc) (label_ref 24))) > > becomes > > (insn (unspec [(label_ref 24)] UNSPEC_REAL_JUMP) > (jump_insn (set (pc) (unspec [(pc)] UNSPEC_JUMP_SHADOW) > > where the first insn emits the branch into the assembly file, while the > second one produces no output (or, in the case of C6X, a helpful comment > that documents that the side effect takes place).
Neat! It'll be interesting to see how easy it would be to convert recog and in-tree delayed-branch targets to use this form instead of SEQUENCEs. It'd certainly be a big step towards keeping the CFG around during and after md-reorg. I might look at that (getting rid of SEQUENCEs in the insn stream) "if I have time". But... ...your message and examples all seem to emphasis unconditional jumps. How good a job does the scheduler do for conditional jumps? E.g. do we steal from the branch target in cases where that's useful? Or, more generally, do you think we're at the stage where all targets could move away from reorg.c to this approach, or do you think more work is needed on the scheduler first? I realise the scheduler won't need to do everything that reorg.c does. Running reorg.c on already-scheduled code (and without pipeline information, and without a proper CFG or DF tracking) has so many oft-discussed downsides that a properly integrated approach could easily be better without copying all the tricks that reorg.c can do. I was just wondering where you think the boundary is. Richard
