RFC & patch: Rework MIPS command-line handling
Maciej W. Rozycki
macro@ds2.pg.gda.pl
Fri Jul 12 11:35:00 GMT 2002
On 12 Jul 2002, Richard Sandiford wrote:
> (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.
Agreed, except that "-mips" options are deprecated, I'm told. But
conceptually OK.
> (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. For example, if "mips64-elf-gcc -mips1" chooses o32 code
> (as it does now) then "mips64-elf-gcc -march=r3000" should do the same.
I'd prefer to select the default ABI at the configure time, from the
target triplet ideally. E.g. I use a local patch that select the 64 ABI
as the default for binutils if configuring for mips64*-*-linux*. The same
is set in the specs file for gcc for this target.
> (3) The GCC code to infer an ABI from an ISA looks like this:
>
> /* A specified ISA defaults the ABI if it was not specified. */
> if (mips_abi_string == 0 && mips_isa_string
> && mips_abi != ABI_EABI
> && mips_abi != ABI_O64
> && mips_abi != ABI_MEABI)
> {
> if (mips_isa == 64)
> mips_abi = ABI_O64;
> else
> {
> if (! ISA_HAS_64BIT_REGS)
> mips_abi = ABI_32;
> else
> mips_abi = ABI_64;
> }
> }
>
> Some problems here:
>
> (a) The o64 exclusion seems strange. Passing -mips1 or -mips2 to
> an o64-configured GCC will generate "32-bit o64" code (we get
> the 32-bit register size from CC1_SPEC). It turns out to be
> almost the same as O32 code, except you get an .mdebug.abiO64
> section instead of an .mdebug.abi32 section.
Hmm, what is "o64"?
> (b) Passing -mips3 to an n32 MIPS III config (e.g. mips-sgi-irix6)
> will select n64, which seems counter-intuitive.
Agreed, I think nothing beside the "-mabi=" and the "-32", "-n32" and
"-64" options should change the default ABI.
> (c) The code takes no account of the -mgp32 option. "-mips4 -mgp32"
> will set the ABI to n64 without complaint, but generate odd code.
> o32 would be a more sensible choice, especially in cases where
> o32 is the default anyway.
As above -- "-mips4" shouldn't change the ABI. The "-mgp32" option seems
redundant, but it may equally well be an alias for "-mabi=o32".
> (d) GAS 2.12 selects o64 (not n64) for -mips3 and -mips4.
>
> 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.
Hmm, how can you enable generating 64-bit code differently from selecting
the "n32" or the "64" ABI?
> (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 "-mgp32" -- see above. And the "-mabi=o32" case is obvious.
> For (i), o64 seems a better choice than n64. Historical precedent
> might be one reason to keep n64, 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.
>
> 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.
As I stated, the best approach I can see is not to switch the ABI
implicitly.
> (4) The code to infer an ISA from an ABI is:
[...]
> Proposed rule in this case:
>
> (i) If the default architecture is 64-bit, -mabi=32 selects
> 32-bit registers, but keeps the current architecture.
>
> (ii) If the default architecture is MIPS I or MIPS II, selecting
> a 64-bit ABI will switch to MIPS III.
>
> (iii) If the default architecture is MIPS 32, selecting a 64-bit
> ABI will switch to MIPS 64.
Agreed.
> With (5), it's no longer necessary for GAS to check the ABI in
> the HAVE_32BIT_* macros, since the register size is always set.
> That means we can remove the ABI field from mips_opts. Also, the
> new error checking means we can get rid of the ABI-killing code
> for -mgp32, -mgp64 and -mfp32:
>
> case OPTION_GP32:
> file_mips_gp32 = 1;
> if (mips_opts.abi != O32_ABI)
> mips_opts.abi = NO_ABI;
> break;
>
> This code seems suspect anyway: it's order-dependent, it silently
> ignores incompatible options, and it means we ignore "-mabi=eabi" if
> followed by "-mgp32" (despite it being a valid combination).
Well, the intent seems valid (certain sets of options make non-conforming
files to be generated), but the check is incomplete. Note the ABI setting
gets propagated to the ELF header of a generated file, so both the ABI
field and the ABI invalidation code like above should probably remain in
place.
> I'd prefer to choose the default CPU in configure: that way, we'd
> get a compile-time error over missing entries, plus we can use globs.
Definitely.
Everything else, I basically agree.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
More information about the Gcc-patches
mailing list