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:
> >> > 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).
> 
> Well, for avoidance of doubt, --with has priority over the vendor-
> specific choices, so really this comes down to what happens when no -mfp
> and --with-o32-fp options are used.

Yes that is what I understood.

> >> 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!
> 
> The ".set mips" handling of gp and fp is really there for local changes
> to the architecture in a .set push/pop or .set mipsN/mips0.  (And IMO we
> the way we do it is a bit of a misfeature, but we have to keep it that
> way for compatibility.)
> 
> I don't think it should apply to .module though.  Ideally .module should
> work in the same way as passing the associated command-line option.

As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option?

Regards,
Matthew