Jeff Law <l...@redhat.com> writes: > Ian Lance Taylor wrote: >> >> 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.
In all of thse cases, the relaxation loop can only affect a handful of instructions: the cases where saving a few less registers moves the offset within range. Those few instructions can only occur in a handful of functions: the ones where the stack frame is so large that this becomes an issue at all. I'm not handwaving away displacement issues in general. I'm handwaving away the need to do relaxation, such that we adjust if we find that need to save one more or one fewer register. If we eliminate that relaxation requirement, we can determine all displacements before register allocation. > 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. We clearly can set maximum offsets, if we are willing to sacrifice an optimization. I argue that that optimization is inconsequential for 99.9% of all code, and avoidable (through refactoring and good inline heuristics) for 100% of all code. Ian
