I’m trying to estimate the work involved in disabling floating point registers on a Sparc back-end.
Currently, I’m not sure how one would go about this. I can’t identify equivalent examples in other processor back-ends.
The desire is that the compiler is still able to handle floating-point operations, but utilizing only integer registers and software floating point support, without using any functions of the processor’s FPU - instructions or registers.
Clearly, disabling FP registers is only the start. The bigger task is getting floating point operations to use the integer registers after that.
Can anyone give any direction on how one might go about this task? I’m not even sure if this is the most pertinent question, but what I think would need to be known, as a start, is “How do you get all floating point values loaded into integer registers rather than floating point registers?”
Best Regards,
Chris Dewhurst, LERO, University of Limerick.
Define another Target, which isn't Sparc, is 32-bit only, and doesn't
have FP registers and/or FP instructions.
It's going to be very difficult to do this inside the existing Sparc
Target. You run the risk of breaking the existing Sparc target, while
never getting Leon3 - or whatever it is that you're working on - to
work correctly.
Much easier starting with a new, clean Target.
--Stefan
Look for the recent -msoft-float support on PPC? That should give you a
decent idea about the SPARC backend as well.
Joerg
I'm trying to estimate the work involved in disabling floating point
registers on a Sparc back-end.
Currently, I'm not sure how one would go about this. I can't identify
equivalent examples in other processor back-ends.
Besides PPC which was already mentioned, you can look at the other
targets which have a useSoftFloat() function.
Clearly, disabling FP registers is only the start. The bigger task is
getting floating point operations to use the integer registers after that.
Actually I think that the bigger task mostly happens automatically
when you've disabled the FP registers. I think you may also need to
put an if around the calls to setOperationAction(..., MVT::f*, Custom)
in SparcISelLowering to avoid invoking the custom expansions which
depend on fp registers.
One possibly-tricky thing is ensuring that the function call ABI looks
as expected -- e.g. does it match what GCC will do with -msoft-float?
That may just work without doing anything, but I'm not sure.