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:
> Richard Sandiford wrote:
> > > 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.
> 
> I don't know about embedded configs. Just have a look at the linux
> kernel. I claim it has nearly no assembly code which could be written
> in an ABI-conformant way, with few performance improvements in assembly
> as an exception.
>
> Having a default ABI is IMHO a good thing in any case: For userland
> code the ABI conformance is essential, and for kernels/embedded configs
> the ABI can provide the default settings which may get overridden then.

I'm still not sure what you're suggesting should be done in the
kernel case.

> > 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.
> 
> Spurious? With some likeliness these are real incompatibilities.

Sure, it could catch real incompatibilities, but it could generate
false positives too.  My point is that, before now, there has been
no default ABI assumption for "mips-elf-as", either invoked directly,
or through the GCC driver.  It hasn't been necessary to think about
ABI flags when assembling (to pick a trivial example):

version:
        .asciz "version (2.10)"

I'm not saying it's necessarily bad to have a default ABI for all
configs, but I just feel that some users might think we're being
a bit too pedantic.

> I heard
> 
> 	mips64-elf-gcc -march=FOO -mlong64
> 
> is used in the embedded world to get 64 bit code and allow FOO's
> opcodes in it. Selecting an ABI definition automatically for e.g.
> FOO == r4000 while keeping "No ABI" for FOO == r5000 would be
> at least surprising.

There isn't a "no ABI" mode in GCC as such.  What we have is ad-hoc
variations on the real ABIs.  So mips64-elf-gcc is o64 by default.
If you specify -mlong64, gcc generates a "long64" version of o64
code (mips_abi == ABI_O64, TARGET_LONG64).  Specifying a 64-bit FOO
would not change the ABI at all wrt just "mips64-elf-gcc -mlong64".

After the patch I sent, specifying a 32-bit FOO would switch to o32,
but you'd get gcc's "long64" version of o32 (just as you would with
"mips-elf-gcc -mlong64").

> > 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.
> 
> For embedded use, I assume. For hosted systems this should be done
> by the ABI.

Well, -mabi isn't the only GCC option that changes the ABI.  At the
moment, you need -mgp32 to select between 32-bit and 64-bit code when
an EABI is selected.  And we have the -msingle-float variations too.
For example:

  -mgp32 -mabi=eabi                     => -mfp32
  -mgp64 -mabi=eabi                     => -mfp64
  -mgp64 -mabi=eabi -msingle-float      => -mfp32

(All supported combinations, I think.)

> > GAS can generate -mgp32 -mfp64 "no ABI" code, so we'd need the
> > -mfp64 option then.  Why anyone would use it, well, who knows?
> 
> I don't see even an half-sane use for it, and it's IMHO a bad idea
> to try to support everything without need.
> 
> > But someone once went to a lot of effort to make it work in GCC too
> > (although it doesn't any more).
> 
> Are you actually talking about the combination -mgp32 -mfp64?

Sadly, yes ;).  E.g., from mips.md:

    (define_insn "movdf_internal1a"
      [(set (match_operand:DF 0 "nonimmediate_operand" "=f,f,R,R,To,To,*d,*d,*d,*To,*R,*d")
            (match_operand:DF 1 "general_operand"      " f,To,f,G,f,G,*F,*To,*R,*d,*d,*d"))]
      "TARGET_HARD_FLOAT && (TARGET_FLOAT64 && !TARGET_64BIT)

Like I say, gcc doesn't support it any more, but someone somewhere
must have cared.  The archive even has patches to fix bugs in
-mgp32 -mfp64 code.

Richard