llvm dev - Mar 2016 - Disabling Sparc (or other) back-end Floating Point registers

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160311/25498317/attachment-0001.html>

On Fri, Mar 11, 2016 at 7:20 AM, Chris.Dewhurst via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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?

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

-- 
Stefan Teleman
KDE e.V.
stefan.teleman at gmail.com

On Fri, Mar 11, 2016 at 12:20:06PM +0000, Chris.Dewhurst via llvm-dev
wrote:
> I'm trying to estimate the work involved in disabling floating point
registers on a Sparc back-end.
Look for the recent -msoft-float support on PPC? That should give you a
decent idea about the SPARC backend as well.

Joerg

On Fri, Mar 11, 2016 at 7:20 AM, Chris.Dewhurst via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.