Ian Lance Taylor wrote:
Jeff Law <l...@redhat.com> writes:
Ian Lance Taylor wrote:
Jeff Law <l...@redhat.com> writes:
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.
You fix the offset of the value stored on the stack. Given that, you
know which instruction you can use.
No, it's not that simple. If you spill, then you can change the
registers that are used and that in turn changes the set of valid
offsets in reg+d instructions.
We are just talking in circles. As I have been saying all along, I'm
suggesting that gcc conservatively determine which registers will be
used. Then spilling will not change the stack space allocated for saved
registers.
Conservatively selecting registers for this case would make the
generated code so bad on this target that GCC would become unusable.
Most of that loop's real work isn't in the address relaxation code,
but in digging through instructions to determine what needs to be
reloaded and how many registers are necessary to perform the requested
reloads.
You are not using the word "relaxation" in the same sense that I meant
it. I meant explicitly the process of finding the final set of
elimination offsets.
Actually I think I am. Very little work of the loop is related to
finding the final set of elimination offsets. Furthermore, most of the
time we run through that loop precisely once. Of the remaining cases
where the loop iterates more than once, 25% can be trivially eliminated
through better sequencing of operations in the loop.
Not a conservative guess at pseudo registers, a conservative guess at
hard registers.
OK. I see the difference here, but it doesn't change the problem at
hand -- a conservative guess at what hard registers we're going to use
would pessimize the code horribly, possibly more so than making a
conservative guess about what offsets are going to be valid -- a
conservative guess on the registers used for these memory operations
would have a cascading effect throughout the code causing a ton of
reloading of other instructions.
Jeff
