Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> >> I think instead we should have a configuration switch that allows a
>> >> particular -mfp option to be inserted alongside -mabi=32 if no
>> >> explicit -mfp is given.  This is how most --with options work.  Maybe
>> >> --with-fp- 32={32|64|xx}?  Specific triples could set a default value
>> if they like.
>> >> E.g. the MTI, SDE and mipsisa* ones would probably want to default to
>> >> -- with-32-fp=xx.  Triples aimed at MIPS IV and below would stay as
>> >> they are.  (MIPS IV is sometimes used with -mabi=32.)
>> >>
>> >> --with-fp-32 isn't the greatest name but is at least consistent with
>> >> --with-arch-32 and -mabi=32.  Maybe --with-fp-32=64 is so weird that
>> >> breaking consistency is better though.
>> >
>> > Tying the use of fpxx by default to a configure time setting is OK
>> > with me. When enabled it would still have to follow the rules as
>> > defined in the design in that it can only apply to architectures that
>> > can support the variant.
>> 
>> Right.  It's really equivalent to putting the -mfp on every command line
>> that doesn't have one.
>> 
>> > Currently that means everything but mips1.
>> 
>> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
>> 
>> > I'm not sure this is the same as tying an ABI to an architecture as
>> > both fp32 and fpxx are O32 and link compatible. Perhaps the configure
>> > switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
>> > related setting.
>> 
>> What I meant is that -march= and -mips shouldn't imply a different -mfp
>> setting.  The -mfp setting should be self-contained and it should be an
>> error if the architecture isn't compatible.
>> 
>> We might be in violent agreement here :-)  Like I say, I was just a bit
>> worried by the earlier -mips32r2 thing because there was a time when a -
>> mips option really could imply things like -mabi, -mgp and -mfp.
>> 
>> --with-o32-fp would be OK with me.  I'm just worried about the ABI being
>> spelt differently from -mabi=, but there's probably no perfect
>> alternative.
>
> I'd like to encourage the perspective that -mfp* options do not lead to
> a different ABI in the same sense that other variations do. While it is
> true that the calling conventions and code generation rules vary, 2 out
> of 3 combinations of -mfp32 -mfpxx and -mfp64 with -mabi=o32 are link
> compatible.

-mfp32 and -mfp64 aren't link-compatible though, so -mfp is part of the ABI.
What you're adding is a new variant that is individually link-compatible
with the other two (but obviously not both simultaneously).  It's a third
ABI variant in itself.

> The introduction of the modeless O32 ABI is intended to
> remove the part of the O32 definition that says 'FR=0' and hence the
> architecture then gets to dictate this and the generated code is still
> O32. It is true today that we have several architectures that mandate
> FR=0, some that cannot support fpxx and some that can support all fp*
> variations. I see nothing preventing the future having an architecture
> only supporting FR=1 though which we should also think about.

Agreed.

> When considering such a scenario it would be highly desirable for the
> following to just work as I believe architectural restrictions should
> be accounted for when designing default options. If the architecture
> gives no choice then it should just work IMO:
>
> Some ideas (speculating that someone builds a core called mips_n with
> only FR=1):
>
> --with-o32-fp=32
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fp32 code 
> mips-*-gcc -march=mips32r2 fp.c ==> generates fp32 code 
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> --with-o32-fp=xx
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fpxx code 
> mips-*-gcc -march=mips32r2 fp.c ==> generates fpxx code 
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> --with-o32-fp=64
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fpxx code 
> mips-*-gcc -march=mips32r2 fp.c ==> generates fp64 code 
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips32r2 -mfpxx fp.c ==> generates fpxx code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> With these defaults, the closest supported ABI is used for each
> architecture based on the --with-o32-fp build option. The only one I
> really care about is the middle one as it makes full use of the O32 FPXX
> ABI without a user needing to account for arch restrictions.

Note that --with-* options just insert a canned -mfoo=bar option under
certain conditions, with those conditions being the same regardless of "bar".
So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32-fp=64
should insert -mfp64, etc.

The rules should therefore be the same for both -mfp and --with-o32-fp.
Should:

  mips-*-gcc -march=mips1 -mfpxx

generate -mfp32 code too?  It seems counter-intuitive to me.

I suppose it depends on what you want -mfpxx to mean.  Do you want it
to mean "use the new ABI that is link-compatible with both -mfp32 and -mfp64"
or do you want it to mean "I don't care what the FR setting is; pick whatever
seems best but be as flexible as possible"?  I'd assumed the former, in which
case using it with an architecture that doesn't support it should be an error.

If you want to go for tha latter meaning then I think we should
be careful to distinguish it from cases where we really are talking
about the new ABI variant.  E.g. an ELF file has to commit to one of
the three modes: you shouldn't have to look at the ELF's architecture
setting in order to interpret the FP setting correctly.  And IMO the
assembly code needs to commit to a specific mode too.  What do you think
should happen for:

      .module fp=xx
      .module arch=mips_n

Should the output be FR=X or FR=1?

> I'm interested to understand the kind of problems that have occurred in
> the past with setting defaults based on architecture. GCC does currently
> at least select default ABI based on 32-bit vs 64-bit arch and this
> would be an extension of that.

Only for certain vendor-specific configurations where there is only one
possible choice.  That's done in configuration-specific spec files.

What I'm talking about here is the generic option handling, which is what
you get on the core mips{,64}-linux-gnu configurations.  If an architecture
implies an ABI, what should happen for:

   mips-linux-gnu-gcc -mips4

?  Should it generate o32 code and use the MIPS IV extensions?  Should it
generate n32 code?  Or n64 code?  Should the answer depend on whether the
builder of the toolchain enabled 64-bit multilibs?  If the user picks a
64-bit architecture on a target that defaults to -mabi=32 or -mabi=eabi
-mgp32, should they sometimes have to explicitly restate that default
option in order for it not to be influenced by the 64-bit architecture?
It just becomes a mess.

And that's the kind of uncertainty we had before.  At Red Hat we had
customers who carried around long strings of command-line options (basically
specifying all of -mips, -march, -mtune, -mabi, -mgp, -mfp, -mlong, etc.)
to make sure they got what they actually wanted.  Which is of course
exactly the opposite of what this "infer as much as we can from the
architecture" approach was supposed to achieve.

Thanks,
Richard