Re: question about register pairs

[Joern Rennecke <joern dot rennecke at embecosm dot com>]

On 25 October 2013 05:15, DJ Delorie <dj@redhat.com> wrote:
>
> Yup, my registers are smaller than Pmode.
>
> This is what I ended up with...
>
> Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
> when it's really one.

Well, it's not really a lie if you map hardware registers 22 and 23 to
a single register for the purposes of gcc internals.  Although it
does make some other things more awkward, e.g. when you
copy fp, and this gets split so you have an insn that copies the
highpart of fp to another register.

> Index: reload.c
> ===================================================================
> --- reload.c    (revision 203733)
> +++ reload.c    (working copy)
> @@ -723,13 +723,15 @@ find_valid_class_1 (enum machine_mode ou
>    unsigned int best_size = 0;
>    int cost;
>
>    for (rclass = 1; rclass < N_REG_CLASSES; rclass++)
>      {
>        int bad = 0;
> -      for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++)
> +      for (regno = 0;
> +          regno < FIRST_PSEUDO_REGISTER && !bad;
> +          regno += HARD_REGNO_NREGS (regno, mode))
>         {
>           if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)
>               && !HARD_REGNO_MODE_OK (regno, mode))
>             bad = 1;
>         }

Seeing the patched code in its entirety like this, I notice that we
would use HARD_REGNO_NREGS
for a regno that's not ok for the mode.
That can be avoided if we put a break into the if.  And then the !bad
term in the loop condition
becomes redundant.
Although the HARD_REGNO_NREGS definition in tm.texi says that HARD_REGNO_NREGS
must never return zero.  That wouldn't be technically violated with an
assert, but I suppose the
spirit of the text is that the macro should return always a
non-positive value, so I suppose this
use of HARD_REGNO_MODE_OK is not actually a problem.