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: MODES_TIEABLE_P for big endian



  In message <200011080049.eA80nli05048@phal.cygnus>you write:
  > tm.h says:
  > 
  > @findex MODES_TIEABLE_P
  > @item MODES_TIEABLE_P (@var{mode1}, @var{mode2})
  > A C expression that is nonzero if a value of mode
  > @var{mode1} is accessible in mode @var{mode2} without copying.
  > 
  > If @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode1})} and
  > @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode2})} are always the same for
  > any @var{r}, then @code{MODES_TIEABLE_P (@var{mode1}, @var{mode2})}
  > should be nonzero.  If they differ for any @var{r}, you should define
  > this macro to return zero unless some other mechanism ensures the
  > accessibility of the value in a narrower mode.
  > 
  > 
  > Does that mean that MODES_TIABLE_P has to return zero for big endian for
  > any mode that occupies more than one hard register?
It seems to imply that.  However I know of ports which are big endian which
do not have MODES_TIEABLE_P return zero modes which are more than one hard
register.

  > local-alloc certainly behaves like this is a requirement.
  > When it ties a multi-hard reg partial integer mode with a single-hard
  > reg integer mode, it allocates a register for the partial integer mode,
  > and wants to use the same register number for the single-hard reg
  > integer mode.
  > 
  > So, is this a design limitation, or is it a bug, that I may fix by
  > doing a big endian correction when assigning a hard register to
  > a pseudo that has a smaller mode than its quantity?
I'm not sure.  What happens when we're not dealing with partial integer
modes?

jeff



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