Re: RFC & patch: Rework MIPS command-line handling

[Richard Sandiford <rsandifo at redhat dot com>]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> I agree, -mipsN should be an alias for the equivalent -march=FOO.
> Please note that the -mipsN options should IMHO be obsoleted:
>
> 	- They are asymmetric because all of them can be replaced by
> 	  -march=FOO, but there are -march=FOO without -mipsN equivalents

I'd guess the ISA levels are more well known than the processors we're
associating them with, so there's probably no harm in keeping them as
aliases, but...

> 	- They are confusing because it's often guessed they do ISA
> 	  selection, but they actually do CPU selection, which is quite
> 	  a difference for GAS. (For current GCC they attempt to do ABI
> 	  selection, too)

...agreed here.

> 	- As CPU aliases they can allow opcodes which aren't available
> 	  on other ISA-conforming CPUs.

Not sure what you mean.  Do you have any examples?

> I don't see a good reason to mix ISA and ABI selection. AFAICS it's
> enough to
> 
> 	- choose the lowest ISA required for a selected ABI
> 
> 	- use the 'highest' ABI for any selected ISA

I'm not sure what you mean by "mix" here.  Anyway, I don't think
it's a good idea to select the lowest ISA for an ABI.  If you have
a configuration that uses a particular CPU by default (let's say a
MIPS II one), specifying an ABI shouldn't "downgrade" to MIPS I.

If someone's using a MIPS II or higher toolchain to generate code
that must run on a MIPS I machine, it doesn't seem unreasonable
to ask them to say so explicitly.

> GCC and GAS have different requirements: For GCC it's sensible to guess
> ISA from ABI and vice versa because it usually handles ABI-conforming
> code. For GAS, the ABI selection is not that useful because assembly
> normally isn't ABI-conformant (which would be limited to opcodes covered
> in the respective ISA).

I agree that might be true for embedded configs.  But like Maciej
said, it could be useful to have a default ABI for hosted toolchains
like mips64-linux-gnu.  It seems reasonable that anyone using such
an assembler would be at least try to write ABI-conformant code.

So the way the GAS config stuff is structured, it will assume NO_ABI
by default, since that seems sensible for most embedded configs,
and won't lead to spurious "incompatible ABI" link failures.
Not setting EF_MIPS_ABI is also the historical behaviour.
There's then the option of overriding the NO_ABI default for
particular configurations.

> >     For example, if "mips64-elf-gcc -mips1" chooses o32 code
> >     (as it does now) then "mips64-elf-gcc -march=r3000" should do the same.
> 
> This may break the 'No ABI' case which means default ABI plus e.g.
> -mlong64 as it is used in the embedded world. OTOH, basing this usage
> on o32/o64 in future is probably a good idea.

I'm not sure how it could break things like that.  -mlong64 only
controls type sizes.

> >     (a) It seems counter-intuitive for -mabi to override the default
> >         architecture even when that default was compatible.  For
> >         example, "mipsisa32-elf-gcc -mabi=o32" would generate
> > 	MIPS I code rather than MIPS 32 code.
> 
> Strictly speaking, MIPS 32 code isn't conforming to o32 ABI.
> The same should be true for MIPS IV opcodes in n32 code.

Hmm... not sure why, but if it's related to...

> This would mean the User can use
> 
> 	gcc -mabi=32
> 
> and then he gets code which might _not_ run on o32 conformant
> Systems. This defeats the idea of having an ABI.

It sounds like you're saying that, because the original o32 systems were
MIPS I only, -mabi=32 should mean "generate MIPS I code" unless the user
says otherwise.  That's the current behaviour, but like I said above,
it seems strange to pick MIPS I regardless of the default processor.

> > 	(OPTION_FP64): New.
> > 	(md_longopts): Add -mfp64, remove -mcpu.
> 
> There's little reason to have -m[gf]p64, see
> http://sources.redhat.com/ml/binutils/2001-07/msg00417.html

One of the changes was that the default float register size would
be worked out from -mgp32, -mgp64, -msingle-float, etc.  That was
mostly for multilib convenience.  GAS can generate -mgp32 -mfp64
"no ABI" code, so we'd need the -mfp64 option then.  Why anyone
would use it, well, who knows?  But someone once went to a lot of
effort to make it work in GCC too (although it doesn't any more).

Anyway, it sounds like there's more support than I expected for
the idea of leaving the ABI unchanged unless the command line
says otherwise.  Which means the special treatment of -mgp32
might not be necessary after all...

Richard