On Wed, Jun 25, 2014 at 10:46 PM, Jeff Law wrote: > On 06/25/14 02:54, Richard Sandiford wrote: >> >> SEQUENCE is just weird though :-) It would be good to have an alternative >> representation, but that'd be a lot of work on reorg. > > Yea. And I don't think anyone is keen on rewriting reorg.
Rewriting/revamping reorg is not really the problem, IMHO. Last year I hacked a bit on a new delayed-branch scheduler, and I got results that were not too bad (especially considering my GCC time is only a few hours per week). The the real problem is designing that alternative representation of delay slots, and teaching the back ends about that. Just communicating a delayed-branch sequence to the back ends is pretty awful (a global variable in final.c) and a lot of back-end code has non-obvious assumptions about jumping across insns contained in SEQUENCEs. There's also one back end (mep?) that uses SEQUENCE for bundles (RTL abuse is not considered bad practice by all maintainers ;-). (I actually found SEQUENCE to be quite nice to work with when I allowed them to be the last insn in a basic block. One of my goals was to retain the CFG across dbr_sched, but that turned out to be blocked by other things than dbr_sched, like fake insns that some back ends emit between basic blocks, e.g. for constant pools). Having some kind of "insns container" like SEQUENCE would IMHO not be a bad thing, perhaps a necessity, and perhaps even an improvement (like for representing bundles), as long as we can assign sane semantics to it w.r.t. next/prev insn. SEQUENCE wasn't designed with its current application in mind... Ciao! Steven
