This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rtlopt loop unroller question
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: drow at mvista dot com (Daniel Jacobowitz)
- Cc: toon at moene dot indiv dot nluug dot nl (Toon Moene), roger at eyesopen dot com (Roger Sayle), rakdver at atrey dot karlin dot mff dot cuni dot cz (Zdenek Dvorak), gcc at gcc dot gnu dot org, YOSSIM at il dot ibm dot com (Yossi Markovich), DORIT at il dot ibm dot com (Dorit Naishlos), aj at suse dot de (Andreas Jaeger)
- Date: Thu, 23 Oct 2003 15:44:01 +0100 (BST)
- Subject: Re: rtlopt loop unroller question
> On Wed, Oct 22, 2003 at 11:38:50PM +0200, Toon Moene wrote:
> > Roger Sayle wrote:
> > What I do not understand is why this part of the compiler thinks that:
> >
> > LD Rx,<const>(Ay)
> > ADD 2^N,Ay ! sizeof(LD access) = 2^N
> >
> > can be replaced by
> >
> > LD Rx,<const>(Ay)+ ! Using autoincrement
> >
> > By far the most architectures that do support autoincrement/decrement do
> > not do so when the address register is offset ...
> >
> > But presumably I'm missing something here.
Daniel Jacobowitz:
> Well, that suggests that ARM may be a good target to try related
> benchmarks on:
> ldr r3, [ip, pc]!
> is "load [ip + pc] into r3 and update ip to ip + pc". #8 works in
> place of pc, too.
>
> I don't know if SH has a similar addressing mode.
No, it doesn't (although an SH4 two-instruction pair for register or small
integer offsets fits into 32 bits and can be executed in a single cycle).
SH1..SH4 / SHcompact have post-increment loads and pre-decement stores where
the increment / decrement is the same size as the data transferred, and no
extra offset is available in these addressing mode.
SHmedia doesn't have any AUTO_INC addressing modes, but lots of general
purpose registers, so strength reduction, biv elimination and unrolling
are generally beneficial.
For the SH32media ABI, givs are often 32 bit wide; by widening them to 64 bit,
biv elimination could be made overflow-safe.