This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Locality Issues/Short Displacements.
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 28 May 2002 13:28:21 +0530
- Subject: Locality Issues/Short Displacements.
Hi,
This is with reference to my earlier message
http://gcc.gnu.org/ml/gcc/2002-04/msg00379.html
1. I earlier said the way gcc treated stack variables
led to intorduction of lot of code whose sole purpose
was to reach desired offset on stack in "reg+offset"
addressing mode.(Refer earlier message)
Now consider the scenario when there are two variables
far apart on the function stack.If they are accessed
adjacently too often in code (beyond displacement provided
on the target) we have too many instructions wasted to reach
them.
Put it in another words, "locality" is not taken care of while
assigning stack offsets.
2. Most of stack allocations are called from reload.Here lies a
complex problem.While stack offset assignments would be most
beneficial before register allocation, the picture of the
stack isn't clear untill reload.
I want that register allocation should benefit from
offset assignments.
Currently I see code segments like this for sh-elf
some_local_var = 0; /* at offset (124+56) from frame pointer)
mov #0,r0
mov #124,r3; Using a extra reg.
add r14,r3 ; r14 is frame pointer
mov.l r0,@(56,r3)
If somehow the offset to local_var is less than 64 (Max displacement on
sh-elf)
(say offset 40) we would get code something like
mov #0,r0
mov.l r0,@(40,r14)
r3 would be freed and it would reduce register pressure resulting
in better code overall.
If I do stack offset assignment after register allocation,
I might get reduction in code size but that would be not be as good
as it won't reduce register pressure during register allocation.
Thoughts and ideas ??
Regards,
Naveen Sharma.