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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Richard Sandiford <rdsandiford@googlemail.com> writes:
> >> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> >> > Are you're OK with automatically selecting fpxx if no -mfp option,
> >> > no .module and no .gnu_attribute exists? Such code would currently
> >> > end up as FP ABI Any even if FP code was present, I don't suppose
> >> > anything would get worse if this existing behaviour simply
> continued though.
> >>
> >> The -mfp setting is usually implied by the -mabi setting.  I don't
> >> think we should change that.  Since this is a new mode, and since the
> >> fpxx markup will be available from the start, everyone using fpxx
> >> should say so explicitly.
> >>
> >> E.g. maybe the rules should be:
> >>
> >> (1) Any explicit .gnu_attribute 4 is always used, although we might
> >>     give a diagnostic if it's incompatible with the module-level
> >> setting.
> >>
> >> (2) Otherwise, if the code does not use FP then the attribute is left
> >>     at the default of 0.
> >>
> >> (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
> >> level
> >>     setting.
> >>
> >> (4) For compatibility, -mabi=32 continues to imply -mfp32.  fpxx mode
> >> must
> >>     be selected explicitly.
> >>
> >> Which was supposed to be simple, but maybe isn't so much.
> >
> > This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
> > FP code but let's see if we can do without it. Setjmp/longjmp are the
> > only obvious candidates for using FP code in assembly files and these
> > need to transition to fpxx.
> >
> > The glibc implementation of setjmp/longjmp is in C so the new defaults
> > from the compiler will lead to this being fpxx as -mips32r2 will imply
> > -mfpxx so that is OK, these modules will be tagged as fpxx.
> 
> Hmm, I don't think -mips32r2 should make any difference here.
> You've specified it so that fpxx will work with MIPS II and above and
> I'd prefer not to have an architecture option implicitly changing the
> ABI.  (They sometimes did in the long-distant past but it just led to
> confusion.)

I didn't mean to single out mips32r2 here it applies equally to anything except mips1 with O32. 

> 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. Currently that means everything but mips1. 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.

> > Currently newlib's implementation is assembly code with no
> > .gnu_attributes. Under the rules above this would start to be
> > implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
> > transition this to fpxx and still have the modules buildable with old
> > tools as well? I'm not sure if it will be acceptable to say that it
> > has to be rewritten in C.
> 
> If it's assembled as -mfpxx then it'll be implicitly tagged with the new
> .gnu_attribute rather than 4,1.  If it's not assembled as -mfpxx then
> 4,1 would be the right choice.

So this would be dependent on the build system ensuring -mfpxx is passed as appropriate if the toolchain supports it. There is some risk in this too if the existing code (which I know is not fpxx safe) gets built with a new toolchain then it will be tagged as fpxx. I wonder if this tells us that command line options cannot safely set the FP ABI away from the default. Instead only the .module and .gnu_attribute can set it as only the source code can know what FP mode it was written for. The change to your 4 points above would be that the module level setting is not impacted by the command line -mfp options.

This would then require us to have an explicit attribute in the source to select fpxx which would need to be optionally included dependent on assembler support for .module. (The relaxation would have helped here of course.)

> Thanks,
> Richard