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

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

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        +