Paolo Bonzini wrote:
Jeff Law wrote:
We'd want to encode [early insn alternative selection]
information in the conflict graph so that IRA would
allocate registers so as to fit the constraints of the early insn
alternative selection. Right? In the case where the graph is
uncolorable, do we allow IRA to override the alternative selection, or
do we insert copies to simplify the conflict graph or some mixture of both?
Inserting compensation code, for example copies, can be seen as some
kind of "pre-reload" as it was used on new-ra branch;
It can certainly be viewed that way; however, it helps me to think in
terms of having IRA generate spill code. The difference is subtle, but
it's helping me get away from the reload-centric mindset which keeps
creeping in.
the problem with
pre-reload was that it was built on "cp reload1.c pre-reload.c", so it
was not much less complicated than reload.
Precisely. And I'm finding that as I look at the existing reload code
and ponder where/how to do things better I always end up with the same
code, but just at a different place in the pipeline. That shouldn't be
the goal here -- the goal should be something more maintainable and
predictable than reload.
What I think I'm getting at is we should be looking at common reload
cases and mapping them into changes to the conflict graph within IRA
(possibly with some copies inserted as compensation code).
Jeff
