This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: autoincrement patches for gcc 4 - updated patch
- From: Ian Lance Taylor <iant at google dot com>
- To: Joern RENNECKE <joern dot rennecke at st dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, Bernd Schmidt <bernd dot schmidt at analog dot com>
- Date: 16 Jul 2006 21:25:34 -0700
- Subject: Re: RFA: autoincrement patches for gcc 4 - updated patch
- References: <421F4698.1050809@st.com> <427136AB.50004@st.com> <20050517025434.GB31389@redhat.com> <428A22F3.4030602@st.com> <20050517171501.GA859@redhat.com> <428A41B3.6050104@st.com> <428B1267.9030004@st.com> <428B36B2.5050001@st.com> <428B4F84.7010302@st.com> <432EF25F.9040305@st.com> <44996F60.8000108@st.com> <m3r70nmz0x.fsf@localhost.localdomain> <44BA44C3.2020109@st.com>
Joern RENNECKE <joern.rennecke@st.com> writes:
> >However, it seems to me that we can view this as two separate
> >optimizations. The first one is to change the first code above into
> >this:
> >
> > r1 = r0 + 8
> > r2 = (r1)
> > r1 = r1 + 4
> > r4 = (r1)
> >
> >On machines without register offset addressing and with relatively few
> >registers, this is a useful optimization because it decreases register
> >pressure.
>
> The code does that too, but only if the number of instructions is not
> increased.
That is good to hear. But I think it might be easier to understand if
it were written as two separate passes, one for this optimization, and
for the auto-increment detection, rather than one complex pass (which
is part of another complex pass).
> >Then the second optimization is to do a better job of recognizing when
> >we can use auto-increment addressing. I know that Ken Zadeck has done
> >some work on this on dataflow-branch.
> >
> Flow doesn't reconize auto-increment opportunities where the related
> addresses
> are held in different registers.
Sure. This is something to fix. If you queue it up with changes like
the above, then I think it will be much easier to detect the
auto-increment opportunities.
> >The patch as it stands, although written in a general manner, seems
> >quite specific to a very small number of processors: those without
> >register offset addressing but with auto-increment addressing. I
> >suspect that FSF gcc supports exactly one processor with that
> >description.
> >
> Note that the addressing modes that are available depend not only on
> the processor,
> but also on the mode of the addressed item - or more general, on the
> instruction and
> the way the value is used in the instruction.
I believe that my point stands.
> >I've been able to run the gcc testsuite on
> >the ARM simulator before, so I know it is possible.
> >
> IIRC I tested the code on an arm simulator already.
Good. I didn't see that in the threads I looked through.
Ian