This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reload work in progress


On 13 Sep 2000, Geoff Keating wrote:

> One other thing which would help to make reload easier to use in a new
> port would be to reduce or eliminate the SECONDARY_* macros.
> 
> All the information needed to eliminate these macros is already
> available in the constraints in every port that doesn't have
> reload_{in,out}* patterns.  For instance, for rs6000 movsi, we have:
> 
> "=r,r,r,m,r,r,r,r, r,*q,*c*l,*h"
> " r,U,m,r,I,L,n,R,*h, r,   r, 0"
> (I've added spaces to make the constraints line up.)
> 
> so suppose reload wants to move from a class 'c' register into memory.
> It sees that there is no 'c' -> 'm' move, but there is a 'c' -> 'r'
> and 'r' -> 'm', so it knows it needs a secondary reload of the class
> of registers that matches 'r' (which happens to be GENERAL_REGS).
> 
> Likewise, for movdf we have:
> 
> "=!r,??r,m,!r,!r,!r,f,f,m"
> "  r,  m,r, G, H, F,f,m,f"
> 
> and reload ought to be able to deduce from that the way to copy
> between registers of classes 'f' and 'r' is to create a temporary of
> class 'm'.

That's a rather cool idea.  I like it a lot.  However, this is something
that should be tackled independently from the changes I'm trying to make.

One thing to keep in mind is that some of the reload_xxx patterns do
special things which are entirely machine-dependent and unknown to reload.
For example, we have one port that emits some reload insns by first
twiddling a control register, then doing the move, then restoring the
control register.  We must take care not to lose this mechanism.


Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]