Re: Why pass HAVE_32BIT_GPRS to OPCODE_IS_MEMBER?

[Richard Sandiford <r dot sandiford at redhat dot com>]

cgd@broadcom.com writes:

> In fact, -mgp32 seems to be intended for when you're running w/o
> 64-bit extensions enabled, on mips3 and later parts.  (e.g. MIPS64
> in user mode with SR:PX set to 0.)

FWIW, that's how I read it too.  It seemed that there wasn't really a
preference for "or" over "addu" if -mgp32 was given.  The original -mgp32
change to the opcode table seemed to be more about avoiding "daddu".

> In that case, you _can't_ get non-canonical values in the registers;
> any operations that you would attempt to produce those values would
> instead trap as reserved or illegal.
>
> I don't know how abi=32 code is intended to be run.  if it simply
> defines calling conventions, and not processor mode, then you need to
> use 'or' rather than 'addu'.  If it defines processor mode as well,
> then addu would be sufficient.

My understanding was that abi=32 should imply processor mode as well.  If
there isn't agreement on that, let me know!  Then I'll go back to using
forced-gpr-32 mode only if -mgp32 is explicitly given.

As it stands, many macros will use 32-bit instructions for address
calculations if abi=32.  These operations would be just as unsafe as an
"addu" move instruction if registers aren't in canonical form.

I don't think that there's really any reason why "move" should be treated
specially here.  It seems to be a choice between register size and ABI
either being linked or being kept seperate.  If people would prefer them
kept separate (the historical behaviour) then I'm willing to change it back.

Richard