Hi!
On Tue, Jan 26, 2021 at 11:47:53AM +0100, Richard Biener wrote:
> Anyway, I think the GIMPLE -> RTL transition currently is a too
> big step
Much agreed. I also think that the expand pass itself needs a lot of
work to bring it into this century: it does much too much work, in a
circuitous way that makes debugging it hard, etc.
> and we should eventually try to lower GIMPLE
That should help the above problem, too: break expand into stages, get
rid of all the premature optimisations (and implement those elsewhere
where needed!), and get a much better debuggable end result (that is
also a lot less code).
> and IV
> selection should happen on a lower form where we for example
> can do the 1st level scheduling on
I don't think that helps, but maybe :-)
> or at least have a better idea
> on resource allocation
This is the holy grail. Wait, I should decorate that:
O_o !!! >>> This is the holy grail. <<< !!! O_o
> and latencies in dependence cycles since
> that's what really matters for unrolling.
I don't think latencies matter much for such decisions. If the compiler
depends too much on actual machine latencies, makes "too sharp"
decisions, the code will run lousy on a slightly different (say, newer)
machine. But certainly there needs to be *some* idea of how parallel
some code can run, yes.
Segher
