Re: Changing the treatment of the MIPS HI and LO registers

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Tue, 27 May 2008, Richard Sandiford wrote:
>
>> We can keep "hi" as a recognised register name for backwards compatibility
>> in clobber lists.  (A lesson learned from removing the old on-the-side
>> "hilo" register, which had even more headaches than this one.  After
>> that change, quite a few linux clobber lists had to be conditional on
>> the compiler version -- sorry about that!)
> [...]
>> Comments?  I'll hold off applying this for 48 hours to see if there
>> are any.  If the patch goes in, I'll add something to the 4.4
>> changes page as well.
>
>  So how do you want to address the compatibility issue with Linux on this 
> occasion?  It uses both the "h" and the "l" constraint in a few places.

I'm afraid they'll just have to use "x".  Although looking at it:

  - delay.h is just doing common-or-garden multiplication, albeit
    with optional R4000 workaounds.  Why not just do them in C?
    Can't you rely on GCC to work around the R4000 errata, now that we
    have -mfix-r4000?

  - div64.h is getting a quotient and modulus.  GCC knows how to use
    the same instruction to get both.

It would be nice if 4.4+ versions could avoid these asms altogether.
If the current -mfix-r4000 support isn't up to the job, please let
me know.

>  If the semantics is to be changed I think the "l" constraint should be
> removed altogether so that code that makes use of it breaks loudly.  We
> have had the "x" constraint to refer to the HI/LO pair as a whole for a
> while now.

Well, code that uses just "l" is fine.  The patch preserves compatibility
with asms that use "l" but not "h".  I'd rather not break it in a way
that might seem gratuitous.

To be clear, "x" is used for doubleword quanities and "l" is used
for single-word (or smaller) quantities.  Which now you mention it
isn't clear from the documentation changes; I'll fix that.

>  You could resurrect the "accum" register since you are creating one.

>From a GCC internals perspective, this doesn't really achieve much.
It is relatively standard practice to model separately-addressable
registers as separate hard registers and use HARD_REGNO_MODE_OK
to model any restrictions on their combination.  That's what we
already do for FPRs on "old" 32-bit ISAs, and what the patch
does for HI and LO.

We also have debugging information to consider.  It is much easier
to keep correct debugging information if we continue to expose
the two registers to GCC.

I don't think there'd be any real win from a backwards-compatiblity
viewpoint either.  We wouldn't really be "resurrecting" accum.
The old accum was never an independent register; it shadowed the
"hi" and "lo" registers.  Any new accum would have different semantics.

Richard