Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[Steven Bosscher <stevenb.gcc@gmail.com>]

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