This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING! [PATCH, RFA] Remove LABEL_NEXTREF and TARGET_ADJUST_UNROLL_MAX from the SH backend
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Joern RENNECKE <joern dot rennecke at st dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 10 Mar 2006 19:32:51 +0100
- Subject: Re: PING! [PATCH, RFA] Remove LABEL_NEXTREF and TARGET_ADJUST_UNROLL_MAX from the SH backend
- References: <200602261725.30716.steven@gcc.gnu.org> <200603101850.26406.steven@gcc.gnu.org> <4411C06E.9010508@st.com>
On Friday 10 March 2006 19:07, Joern RENNECKE wrote:
> Steven Bosscher wrote:
> >Patch at http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01935.html is
> >still not reviewed. Could an SH maintainer or a GWP maintainer give
> >it a look please?
>
> The removal of the TARGET_ADJUST_UNROLL_MAX code is inappropriate, since
> you haven't put any viable replacement in place.
Perhaps you can explain why _I_ should put a viable replacement
in place for it? Don't say "because you are removing it" because
you know just as well as I do that what I remove is alraedy dead
code. The hook refers to the old RTL loop unroller which was
removed a full 18 months ago! In fact, the SH backend is the only
backend that defines TARGET_ADJUST_UNROLL_MAX at all. And if a
grep of {FSF,}ChangeLog* is reliable, there never was any other
backend that implemented it.
Anyway, that's not really interesting as far as I'm concerned, all
I really wanted to do is remove LABEL_NEXT_REF. That's orthogonal
to removing TARGET_ADJUST_UNROLL_MAX. So if you'd like to keep
that hook, then let's leave it there.
Leaving it means the reference to LABEL_NEXTREF stays too, but I
guess that's OK because the hook as it is implemented in the SH
backend also refers to other stuff that doesn't exist anymore in
the compiler (e.g. struct loop_ivs, struct iv_class).
So...
Is it OK with you if the part that just makes the SH backend not
use LABEL_NEXTREF goes in? Only the SH backend uses it, so if my
patch can go in then I can remove LABEL_NEXTREF in a follow-on
patch. If you say no, I'd like to have a really good explanation
why.
Thanks,
Gr.
Steven