Ian Lance Taylor wrote:
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.
Just fixing the offset is not sufficient for the case I'm concerned
about because you don't know what offsets are valid until you know
precisely what registers are used in the insn. That's absolutely
critical. So you have to assume worst case which is you can only use
the +-16 byte insns which will pessimize just about every stack reference.
Perhaps the confusion in this case is because we're not really relaxing
-- we're dealing with a case where the offset alone isn't enough to
determine if the addressing mode is valid.
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).
In the case I'm talking about, it will affect a huge number of insns.
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.
But the offsets are relative to the size of the frame. So I don't see
how you can set the offsets without knowing the size of the frame.
Clearly neither of us is understanding what the other is saying.
Jeff
