RFA: 4.2 reload infrastructure to fix PR target/21623

amylaar@spamcop.net amylaar@spamcop.net
Sun Oct 9 15:13:00 GMT 2005


Quoting Bernd Schmidt <bernds_cb1@t-online.de>:


> >> Not sure I agree with the comments about recursion. Isn't there a mismatch
> >> between what targetm.secondary_reload_class wants (an rtx) and what we can
> give
> >> it (an intermediate class and mode)?
>
> Any comments?

We still use the same rtx x.  The reg class of the original reload is replaced
with the reg class of the intermediate register.
>
> > I've enumerated a couple of things earlier in this thread:
> > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00099.html
>
> Ok.  Let's not overdesign it, however.  I dread an attempt to make
> lifetimes more accurate with the current set of RELOAD_FOR_FOO lifetime
> descriptions.

Yes, we better leave that for when we have sane dependency information.
>
> >>Does the sh need multiple intermediate registers for any of its secondary
> >
> > reloads?
> >
> > Yes, that is what originally started this thread.  In order to copy the
> > T register to FP_REGS, the copy has to go through GENERAL_REGS and
> FPUL_REGS.
>
> How common is this?

Rather rare, but you have to handle it somehow.  And I would like to have
an interface that doesn't need to be rewritten again when we find we need
this temporary register inheritance to get decent performance.
>
> > However, if we don't describe intermediate registers as they are and
> > allow to use them to reduce more comples reload problems to simpler reload
> > problems, the coding effort for a port maintainer is quadratic with the
> > length of the chain of copies needed.  Moreover, these unnecessaryly large
> > reload patterns make the process harder to understand.
>
> I'd say it depends how often we need something like this.  If it's only
> a rare one-off case in the sh backend, then I think we're better off
> just slightly extending the current scheme along the lines of the patch
> you posted.  If it happens more frequently for more ports, then it might
> be warranted to look for another approach, but the interface will be
> quite different from what we have now.

My intention was to make the interface so that it can support any reload
problem with intermediate registers, memory and/or scratch registers,
but have the implementation only support what is currently needed, or
what we get more or less for free.  That'll be pretty much the same
implemented functionality as with my first patch, but the interface will
allow to express more complicated cases in a sane manner.  At the point
where the implementation is incomplete we can have gcc_unreachable()s
with appropriate comments so when somebody hits this, (s)he knows that
this is merely a matter of an incomplete implementation.

> Having the ability to use separate patterns for different needs should
> already help with the understandability, shouldn't it?

Yes, it solves one of the problems.  But Ian has a point that the way
we specify intermediate registers at the moment is a bit convoluted.
The class can come from the SECONDARY_RELOAD_CLASS macro, or from the
constraint of a pattern, if we give an icode for one.  With my latest
proposal, the class of an intermediate register would always be the
return value of the target hook.  For input reloads, The returned
register class basically says:
before x can be loaded into the reload register, it need to be loaded
into an intermediate register of this register class first (which is a
separate problem).  The icode says how to load the the reload register
from the intermediate register, of from x if there is no intermediate
register.  Likewise, for output reloads, the intermediate register specified
by the hook is a class that the reload register is copied to first, with
the help of a pattern if necessary, and the store of the intermediate
register is a separate reload problem.



More information about the Gcc-patches mailing list