This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (i386-linux x sh-elf) More weak stack addressing
- To: Joern Rennecke <amylaar at pasanda dot cygnus dot co dot uk>
- Subject: Re: (i386-linux x sh-elf) More weak stack addressing
- From: Toshiyasu Morita <tm at netcom dot com>
- Date: Thu, 20 Jul 2000 15:06:35 -0700 (PDT)
- cc: Joern Rennecke <amylaar at pasanda dot cygnus dot co dot uk>, gcc-bugs at gcc dot gnu dot org dot gcc, gcc at gcc dot gnu dot org
On Wed, 19 Jul 2000, Joern Rennecke wrote:
> > I suspect a more comprehensive solution is required.
> >
> > Even with this patch, I see the following generated elsewhere:
> >
> > 6237:vtkTriangleStrip.ii **** cell->DeepCopy(*this);
> > 49924 0280 FC7F add #-4,r15
> > 49925 0282 7CE7 mov #124,r7 <- here
> > 49926 0284 6F93 mov.w .L103,r3
> > 49927 0286 EC37 add r14,r7 <- here
> > 49928 0288 7A52 mov.l @(40,r7),r2
> > 49929 028a EC33 add r14,r3
> > 49930 028c 7A57 mov.l @(40,r7),r7
> > 49931 028e 2351 mov.l @(12,r2),r1
> > 49932 0290 6077 add #96,r7
> > 49933 0292 7713 mov.l r7,@(28,r3)
>
> What else would you do, with only r3 and r7 available as reload registers?
> sometimes there just aren't enough reload registers to go around.
>
> I tried a more elaborate patch that peeks ahead what reloads are
> actually useful for future inheritance, but it actually results in
> one more assembler line for your testcase.
> Well, unless you peek ahead beyond labels, then it saves 5 lines,
> but such a strategy doesn't really make any sense.
Maybe I'm missing something, but it seems peeking beyond labels is
extremely important for the Hitachi SH. Forgive me for overexplaining
a bit - I'm basically explaining my assumptions to see if people
can spot any glaring oversights.
Consider:
The SH uses pc-relative addressing to load large constants,
therefore it generates literal pools in the .text segment. These
literal pools must be "jumped around" to continue execution.
From a code analysis perspective, these jumps aren't really jumps
since they jump to a label accessed by only a single jump. Therefore
the jump destination can be considered in the same block as the jump
source.
If an optimization pass assumes a jump ends a basic block, it will miss
many potential optimiations.
I think one example of this is regmove. If I remember correctly from an
old PR, it misses many potential optimization opportunities in C++
exception handling code for the Hitachi SH because many literal pools are
generated, and regmove assumes the basic block ends at the jump around
the literal pool.
Toshi