Ian Lance Taylor wrote:
Paolo Bonzini <bonz...@gnu.org> writes:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displacement
constraints, before register allocation. Carefully relaxing these
constraints during reload can give you slightly better results for some
instructions, but only in very very few cases, and only in functions
which already have unusually large stack frames. I don't consider that
to be an important optimization. Given that, we can determine the
maximum offset for all virtual registers before register allocation,
which suffices for selection of insn constraint alternatives, and then
determine the actual offset, once, after register allocation.
Ian, sorry for not to be clear which resulted in this misunderstanding.
What I wrote was a scheme without reload pass. I just mentioned some
tasks of reload pass which should be solved in RA without the reload and
whose solutions I did not discussed in details. The solution could be
what you propose for example.
Removing reload is a long way, imho. If we go this way, in the middle of
it there would be still reload but solving less and less tasks.
