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.
I would agree that careful relaxation of displacements is no longer as
important as it once was, I don't think we can just hand wave away the
displacement issues
1. The stack frames don't have to be that big to bump up against these
problems.
2. The code we generate if we have to reload the address because the
displacement was out of range can be horrific
3. There are targets where other registers used in the insn determine
the range of the displacement. ie, in a load from memory, the
destination register used determines the valid range of displacements
(+-16 bytes vs +-8k on one target I'm aware of.
4. Register eliminations complicates matters as well. Enough that I
don't think you can set maximum offsets until you've finalized
everything in the stack -- which implies that you're done spilling.
Jeff
