Richard Sandiford <rdsandif...@googlemail.com> writes > Doug Gilmore <doug.gilm...@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
