Question about constraints and reload

[Ulrich Weigand]

Steven Bosscher wrote:

> You conveniently ignored my remark about reload redoing almost complete
> register allocations after the register allocator.  Apparently you do not
> think that is odd.

I don't see reload as redoing register allocation.  As I said, I my view
the primary purpose of reload is to choose operands in a way to best fit
the available machine instructions.

I agree that the way this task is currently intertwined with generating
spill code required to satisfy register pressure is not optimal.  Handling
spill code as just one variant of reloads generates very inefficient code;
and while reload avoids that extreme by measures like reload inheritance
and post-reload CSE, all this is not only quite fragile, but not as
efficient as it probably could be ...

> We'll probably always need reload of some form.  But one way or another
> we will have to provide an instruction stream to the register allocator on
> which it can do its job properly, without getting overruled by reload.

My feeling is that this order may not work well; the final decision on
which instruction forms to choose should IMO stay with reload or something
like it, but it should be integrated with a proper register allocator
to implement all the spill code.  (Maybe similar to how the reload
currently calls back into the register allocator for re-evaluation
after reload itself has generated additional register pressure; only
that the (old) register allocator doesn't do any spilling.)

Anyway, I haven't really looked into this issue in detail, so feel
free to ignore me. ;-)  I just don't think that you can handle the
intricate machine-specific details all up-front, and then run a 
generic algorithm; it usually needs to be the other way round
(or completly integrated with each other in the first place).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de