Jeff Law <l...@redhat.com> writes: >>> 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 disagree, particularly because of point #3. I don't see how you > can hand wave it away, that is unless you plan on just making every > load/store of a stack variable/spill be assumed to be out of the +-16 > byte range which will generate absolutely horrible code.
No, that makes no sense. What I'm suggesting is that we fix the stack offsets of all local variables before register allocation, based on a conservative assessment of how many registers will be saved on the stack. Then we know during register allocation whether the memory reference will be in or out of the +- 16 byte range. What we lose is the ability to discover that our conservative assessment was overly conservative, and so actually some small number of instructions will be generated as out of range when they could have been in range. (Of course we will pick up some of those cases using peepholes). > Without knowing the size of the frame, how do you plan on doing this > without making the assumption that nothing is going to fit in the > shorter displacement variants? How can you do this when the range of > valid displacements can change because the register you used got > spilled and you got a register from a different class (which in turn > has a drastically smaller set of valid displacements). I'm saying that you guess the size of the frame, so your premise does not describe the aproach that I am suggesting. Ian
