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
> Doug Gilmore <Doug.Gilmore@imgtec.com> writes:
> > On 02/24/2014 10:42 AM, Richard Sandiford wrote:
> >>...
> >>> AIUI the old form never really worked reliably due to things like
> >>> newlib's setjmp not preserving the odd-numbered registers, so it
> >>> doesn't
> >>>> seem worth keeping around.  Also, the old form is identified by the
> >>>> GNU attribute (4, 4) so it'd be easy for the linker to reject links
> >>>> between the old and the new form.
> >>>
> >>> That is true. You will have noticed a number of changes over recent
> >>> months to start fixing fp64 as currently defined but having found
> >>> this new solution then such fixes are no longer important. The lack
> >>> of support for gp32 fp64 in linux is further reason to permit
> >>> redefining it. Would you be happy to retain the same builtin defines
> >>> for FP64 if changing its behaviour (i.e. __mips_fpr=64)?
> >>
> >>I think that should be OK.  I suppose a natural follow-on question is
> >>what __mips_fpr should be for -mfpxx.  Maybe just 0?
> > I think we should think carefully about just making -mfp64 just
> disappear.
> > The support has existed for bare iron for quite a while, and we do
> > internal testing of MSA using -mfp64.  I'd rather avoid a flag day.
> > It would be good to continue recognizing that object files with
> > attribute (4, 4)
> > (-mfp64) are not compatible with other objects.
> 
> Right, that was the idea.  (4, 4) would always mean the current form of
> -mfp64 and the linker would reject links between (4, 4) and the new -
> mfp64 form.
> 
> The flag day was more on the GCC and GAS side.  I don't see the point in
> supporting both forms there at the same time, since it significantly
> complicates the interface and since AIUI the old form was never really
> suitable for production use.

That sounds OK to me.

I'm aiming to have an experimental implementation of the calling convention changes as soon as possible although I am having difficulties getting the frx calling convention working correctly.

The problem is that frx needs to treat registers as 64bit sometimes and 32bit at other times.
a) I need the aliasing that 32bit registers gives me (use of an even-numbered double clobbers the corresponding odd-numbered single. This is to prevent both the double and odd numbered single being used simultaneously.
b) I need the 64bit register layout to ensure that 64bit values in caller-saved registers are saved as 64-bit (rather than 2x32-bit) and 32-bit registers are saved as 32-bit and never combined into a 64-bit save. Caller-save.c flattens the caller-save problem down to look at only hard registers not modes which is frustrating.

It looks like caller-save.c would need a lot of work to achieve b) with 32-bit hard registers but I equally don't know how I could achieve a) for 64-bit registers. I suspect a) is marginally easier to solve in the end but have to find a way to say that using reg x as 64-bit prevents allocation of x+1 as 32-bit despite registers being 64-bit. The easy option is to go for 64-bit registers and never use odd-numbered registers for single-precision or double-precision but I don't really want frx to be limited to that if at all possible. Any suggestions?

The special handling for callee-saved registers is not a problem (I think) as it is all backend code for that (assuming a or b is resolved).

Regards,
Matthew