This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Sun, 14 Jul 2002 19:22:00 +0200
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- References: <firstname.lastname@example.org>
Richard Sandiford wrote:
> [cross-posted to binutils & gcc]
> The patch below tries to make MIPS GCC and GAS more consistent in
> the way they handle command-line options. This message is really a
> RFC on whether it's the right way to go, although the patch has
> been tested in the usual way.
> I'll use numbers to break things up...
> (1) The main discrepancy I see with the current set-up is in the handling
> of -march. In GAS, it fully controls the ISA, much like -mipsN does,
> but in GCC it only controls the use of processor-specific extensions.
> So, for example,
> mips-elf-as -march=r8000
> selects MIPS IV code but
> mips-elf-gcc -march=r8000
> selects MIPS I code. I'd like to make it so that both cc1 and gas treat
> -march like a more descriptive version of -mipsN. -march=r8000 would
> be equivalent to -mips4, -march=r4000 would be equivalent to -mips3,
> and so on.
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
- 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
- As CPU aliases they can allow opcodes which aren't available
on other ISA-conforming CPUs.
> (2) Traditionally, GCC has tried to infer sensible things from a sparse
> command line. Passing -mipsN would select a suitable ABI for ISA N,
> passing -mabi=FOO would select a suitable ISA for ABI FOO, and so on.
> Lately, gas has done the same thing, although the assumptions are
> slightly different (more later).
> If -march is going to act like -mipsN, then it ought to choose the
> ABI as well.
I don't see a good reason to mix ISA and ABI selection. AFAICS it's
- choose the lowest ISA required for a selected ABI
- use the 'highest' ABI for any selected ISA
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).
> 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.
> The proposed new rule is:
> (i) If the default ABI requires 32-bit registers [o32 only] then
> switch to o64 when generating 64-bit code.
> (ii) If the default ABI requires 64-bit registers [o64, n32 and 64]
> then switch to o32 when generating 32-bit code.
> Here, "generating X-bit code" takes into account the ISA and
> -mgp32 option.
> For (i), o64 seems a better choice than n64. Historical precedent
> might be one reason to keep n64,
AFAICS n64 isn't a good idea anyway because it's less performant than
n32 and only needed for large memory applications. n32 still needs some
work to get usable, so o64 is the best choice for now.
> but GAS prior to 2.12 didn't support
> it and (like (d) says) gas 2.12 would assume you meant o64 instead
> of n64. So I can't see the n64 choice would ever have worked
> well when using GAS.
Currently it works only for non-PIC and has little testing.
> Choosing o64 shouldn't hurt mips-sgi-irix6. Since its default ABI
> is n32, (i) would mean you still get n32 code after passing -mips3
> or -mips4. You can switch to n64 using -mabi=64 in the usual way.
> (4) The code to infer an ISA from an ABI is:
> /* A specified ABI defaults the ISA if it was not specified. */
> else if (mips_isa_string == 0 && mips_abi_string
> && mips_abi != ABI_EABI && mips_abi != ABI_O64)
> if (mips_abi == ABI_32)
> mips_isa = 1;
> else if (mips_abi == ABI_N32)
> mips_isa = 3;
> mips_isa = 4;
> Problems here:
> (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.
> (b) MIPS III and MIPS IV processors can run o32 too, and you can
> sometimes get the benefit of extra instructions (like
> conditional moves, and sometimes multiply-add). It seems
> more appropriate to generate 32-bit code for the default
> architecture when passed -mabi=o32, rather than blindly
> switching to MIPS I.
Same problem as above.
> (b) There seems no good reason why we should choose MIPS IV over
> MIPS III for n64. People have complained: see PR #5938.
SGI's n64 ABI is IIRC only available on MIPS IV machines, so they
have no problem to generally prefer MIPS IV for it. Maybe GNU should
> Proposed rule in this case:
> (i) If the default architecture is 64-bit, -mabi=32 selects
> 32-bit registers, but keeps the current architecture.
This would mean the User can use
and then he gets code which might _not_ run on o32 conformant
Systems. This defeats the idea of having an ABI.
> (OPTION_FP64): New.
> (md_longopts): Add -mfp64, remove -mcpu.
There's little reason to have -m[gf]p64, see