Richard Sandiford <rdsandif...@googlemail.com> writes:
> Matthew Fortune <matthew.fort...@imgtec.com> writes:
> > Richard Sandiford <rdsandif...@googlemail.com> writes:
> >> Matthew Fortune <matthew.fort...@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.
In the end I do just want fpxx to mean use the new ABI that is link-compatible.
I think I have managed to confuse this discussion by not
understanding/separating vendor specific specs from generic option handling as
you explain later in your email. I only really wish to allow a vendor specific
config to infer a suitable default fp option from -march (like -mabi=32 for
32-bit arch and -mabi=n32 for 64-bit arch).
> 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?
Well, even defining fpxx as simply being another abi variant there are some
issues. The current .set arch= options set fp32 for 32-bit architectures and
fp64 for 64-bit architectures which means we do have to come up with some
definition of how fpxx interacts with this. My current implementation is that,
for .set arch, the fp option is only changed if the existing setting is
incompatible with the new arch. So carrying that logic to .module means that in
the case above then the output would be FPXX. Other examples would then be:
.module fp=xx
.module arch=mips_n
<FPXX>
.module fp=32
.module arch=mips_n
<FP64>
.module fp=xx
.module arch=mips2
<FPXX>
.module fp=64
.module arch=mips2
<FP32> (existing behaviour for .set)
.module fp=xx
.module arch=mips1
<FP32>
.module fp=64
.module arch=mips1
<FP32> (existing behaviour for .set)
This is weird though for the same reasons as you point out. You have to know
the arch to know what happens to the FP mode. If we just continued with 32-bit
arch setting fp=32 and 64-bit setting fp=64 then we have a problem with
something like mips_n where fp=32 would be invalid. I really don't know what is
best here!
> > 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.
Good point, and this is actually what I want to ensure is allowed not anything
to do with generic option handling.
> 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.
Thanks. I've been too focussed on vendor specific configs. Any special
behaviour must be constrained to a vendor config.
> 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.
Indeed. This is a risk we will still face by having special behaviour in vendor
configs but in order to ship a single toolchain with multilibs that support a
variety of architectures then we need the flexibility to infer information from
architecture. In some ways this is no more surprising than a user taking a
generic toolchain that is configured with one set of --with options and then
moving to a different one configured with a different set of --with options.
Inferring options is however the only way we can encourage users to build code
in a certain way for reasons they may not want or need to understand. I expect
careful consideration of the user base and the overall goal is then all we can
use to dictate how far a vendor config would/should push special behaviour.
Regards,
Matthew
