From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: gcc-patches@gcc.gnu.org, binutils@sources.redhat.com
Subject: Re: RFC & patch: Rework MIPS command-line handling
Date: Fri, 12 Jul 2002 11:39:00 -0000 [thread overview]
Message-ID: <Pine.GSO.3.96.1020712194308.7646E-100000@delta.ds2.pg.gda.pl> (raw)
In-Reply-To: <wvnfzyodh02.fsf@talisman.cambridge.redhat.com>
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 +
next prev parent reply other threads:[~2002-07-12 18:21 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-12 10:16 Richard Sandiford
2002-07-12 11:39 ` Maciej W. Rozycki [this message]
2002-07-12 12:28 ` Paul Koning
2002-07-15 4:50 ` Richard Sandiford
2002-07-15 13:18 ` Thiemo Seufer
2002-07-15 13:31 ` Eric Christopher
2002-07-15 13:59 ` Thiemo Seufer
2002-07-15 14:25 ` Eric Christopher
2002-07-15 14:30 ` Thiemo Seufer
2002-07-15 14:59 ` Eric Christopher
2002-07-15 15:04 ` Thiemo Seufer
2002-07-15 17:26 ` Eric Christopher
2002-07-16 3:54 ` Maciej W. Rozycki
2002-07-16 4:47 ` Mark D. Baushke
2002-07-16 11:33 ` Eric Christopher
[not found] ` <mailpost.1026843855.9110@news-sj1-1>
2002-07-16 18:18 ` cgd
2002-07-17 2:19 ` Maciej W. Rozycki
2002-07-17 15:18 ` Eric Christopher
2002-07-12 11:46 ` Eric Christopher
2002-07-12 12:46 ` Maciej W. Rozycki
2002-07-12 18:16 ` Eric Christopher
[not found] ` <mailpost.1026512166.22848@news-sj1-1>
2002-07-13 19:56 ` cgd
2002-07-15 5:39 ` Richard Sandiford
2002-07-14 11:38 ` Thiemo Seufer
2002-07-15 1:03 ` Maciej W. Rozycki
2002-07-15 3:13 ` Mark D. Baushke
2002-07-15 6:40 ` Richard Sandiford
[not found] ` <mailpost.1026503036.18648@news-sj1-1>
2002-07-13 0:52 ` cgd
2002-07-14 11:22 ` Thiemo Seufer
[not found] ` <mailpost.1026499181.16972@news-sj1-1>
2002-07-13 0:42 ` cgd
2002-07-14 10:53 ` Thiemo Seufer
2002-07-14 23:13 ` Maciej W. Rozycki
[not found] ` <mailpost.1026493441.14222@news-sj1-1>
2002-07-13 0:40 ` cgd
2002-07-15 5:07 ` Richard Sandiford
[not found] ` <mailpost.1026733871.20742@news-sj1-1>
2002-07-15 11:04 ` cgd
2002-07-15 14:28 ` Eric Christopher
2002-07-16 3:23 ` Richard Sandiford
2002-07-16 12:16 ` Eric Christopher
[not found] ` <mailpost.1026812813.25035@news-sj1-1>
2002-07-16 17:48 ` cgd
2002-07-14 10:43 ` Thiemo Seufer
2002-07-15 3:40 ` Richard Sandiford
2002-07-15 3:57 ` Mark D. Baushke
[not found] ` <mailpost.1026729642.18965@news-sj1-1>
2002-07-15 10:54 ` cgd
2002-07-15 11:02 ` Mark D. Baushke
2002-07-15 11:11 ` cgd
[not found] ` <mailpost.1026728027.18467@news-sj1-1>
2002-07-15 10:47 ` cgd
2002-07-15 11:22 ` Thiemo Seufer
[not found] ` <mailpost.1026757359.1135@news-sj1-1>
2002-07-16 17:24 ` cgd
2002-07-18 12:48 ` Thiemo Seufer
2002-07-18 13:09 ` Eric Christopher
2002-07-16 4:04 ` Maciej W. Rozycki
2002-07-15 11:01 ` Thiemo Seufer
[not found] ` <mailpost.1026755685.506@news-sj1-1>
2002-07-15 11:24 ` cgd
2002-07-15 12:51 ` Thiemo Seufer
2002-07-16 3:57 ` Maciej W. Rozycki
2002-07-18 13:43 ` Thiemo Seufer
[not found] ` <mailpost.1026759415.2116@news-sj1-1>
2002-07-16 17:34 ` cgd
2002-07-16 18:56 ` H. J. Lu
2002-07-16 18:57 ` cgd
2002-07-18 13:57 ` Thiemo Seufer
2002-07-16 4:45 ` Maciej W. Rozycki
2002-07-16 5:31 ` Richard Sandiford
2002-07-16 11:39 ` Eric Christopher
2002-07-18 14:44 ` Thiemo Seufer
2002-07-16 2:40 ` Richard Sandiford
2002-07-18 13:36 ` Thiemo Seufer
2002-07-16 4:17 ` Maciej W. Rozycki
2002-07-16 2:46 ` Maciej W. Rozycki
2002-07-16 8:01 ` Paul Koning
2002-07-16 11:01 ` Maciej W. Rozycki
2002-07-18 12:44 ` [Revised patch] " Richard Sandiford
2002-07-18 13:44 ` cgd
2002-07-18 18:12 ` Eric Christopher
2002-07-19 2:53 ` Richard Sandiford
2002-07-19 3:10 ` Mark D. Baushke
2002-07-19 10:11 ` cgd
2002-07-19 9:56 ` cgd
2002-07-22 3:47 ` Richard Sandiford
2002-07-22 4:19 ` Gerald Pfeifer
2002-07-22 11:13 ` Maciej W. Rozycki
2002-07-22 11:21 ` Richard Sandiford
2002-07-22 11:53 ` Eric Christopher
2002-07-22 12:12 ` Paul Koning
2002-07-22 13:13 ` Eric Christopher
[not found] ` <mailpost.1027334536.9318@news-sj1-1>
2002-07-22 15:13 ` cgd
2002-07-23 2:03 ` Richard Sandiford
[not found] ` <mailpost.1027412600.13407@news-sj1-1>
2002-07-23 9:42 ` cgd
2002-07-23 9:42 ` Richard Sandiford
2002-07-23 10:04 ` cgd
2002-07-23 10:16 ` Richard Sandiford
2002-07-23 10:24 ` cgd
2002-07-23 10:44 ` Richard Sandiford
2002-07-23 10:52 ` cgd
2002-07-23 11:38 ` Richard Sandiford
2002-07-23 13:18 ` Eric Christopher
2002-07-25 3:03 ` Richard Sandiford
2002-07-18 16:32 ` Thiemo Seufer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.3.96.1020712194308.7646E-100000@delta.ds2.pg.gda.pl \
--to=macro@ds2.pg.gda.pl \
--cc=binutils@sources.redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rsandifo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).