This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MODES_TIEABLE_P for big endian
- To: Joern Rennecke <amylaar at redhat dot com>
- Subject: Re: MODES_TIEABLE_P for big endian
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 07 Nov 2000 20:48:34 -0700
- cc: gcc at gcc dot gnu dot org
- Reply-To: law at redhat dot com
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