Re: PING! [PATCH, RFA] Remove LABEL_NEXTREF and TARGET_ADJUST_UNROLL_MAX from the SH backend

[Joern RENNECKE <joern dot rennecke at st dot com>]

Steven Bosscher wrote:

>  
>
> 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.
>  
Well, as I said, there is no current infrastructure that allows to fully 
implement
the functionality.  And I don't have time to instantly replace 
infrastructure that
someone else rips out.

> 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).
>  
Yes.  The code might not compile in the current sources as it is, but at 
least it
gives an outline what has to be done when we get suitable support 
infrastructure
back in place.

> Is it OK with you if the part that just makes the SH backend not
> use LABEL_NEXTREF goes in?
Yes.  Subject to the usual rules if this causes regressions... I didn't 
actually write the
code that added windows to the constant pools, so I'm not very good at 
judging if
your change is most suitable to replace the LABEL_NEXTREF use there, but 
I don't
see anything obviously wrong with it.