Support for Soft-float

Hi,

I’m trying to generate some SPARCv8 assembly for a sparc target that doesn’t have an FPU. I’m unable to get the flow to generate calls to a soft-float library. Since I wasn’t able to find a definitive answer, I was hoping someone might be able to offer some pointers or shed some light.

Running “clang -c -emit-llvm -msoft-float test.c -o test.bc” doesn’t generate IR with soft-float library calls (perhaps understandably) - only hard float instructions. I would expect the frontend to at least be able to generate the library calls even though I’m not asking it to link to any library yet.

Running “llc -march=sparc -soft-float test.bc -o test.s” next still does not replace the hard float instructions with soft-float calls. Is this a known issue, am I doing something wrong, etc.?

Just as a test, I see that running “llc -march=arm -soft-float test.bc -o test.s” will indeed generate the appropriate soft-float library call. I checked using mips, x86, ppc32, etc. and it seems that only the arm target actually generates the soft-float call.

Is there a reason many of the backend targets will not generate the library call? Is there some way to fix this?

Thanks,
Eric

Hi Eric,

Running "clang -c -emit-llvm -msoft-float test.c -o test.bc" doesn't generate IR with soft-float library calls (perhaps understandably) - only hard float instructions. I would expect the frontend to at least be able to generate the library calls even though I'm not asking it to link to any library yet.

I think you have to explicitly pass the target. For an example:

./clang -c -emit-llvm -msoft-float test.c -o test.bc -###

Does not show -msoft-float passed into the backend. Whereas the following invocation does:

./clang -target sparc-none-linux-gnu -c -emit-llvm -msoft-float test.c -o test.bc -###

May be give this a try and see if it produces the correct lib calls?

I happened to be working on something related (for ARM).

- Asiri

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

And, Apologies for the footer. Wrong account.

Best,

- Asiri

Hi Asiri,

Unfortunately, I had also tried using the -target switch previously ("-target sparc", “-target arm”, etc.). However, since it ultimately made difference, I left it out of my example for brevity.

Thanks,
Eric

Running "clang -c -emit-llvm -msoft-float test.c -o test.bc" doesn't
generate IR with soft-float library calls (perhaps understandably) - only
hard float instructions. I would expect the frontend to at least be able to
generate the library calls even though I'm not asking it to link to any
library yet.

Hi Eric,

If you mean "IR floating point instructions", than this is correct.
The front-end doesn't know what the back-end is capable of (hard
multiply, divide etc), so it emits "fp instructions" and the back-end
will then generate the correct call/instruction for each separate
case.

Running "llc -march=sparc -soft-float test.bc -o test.s" next still does not
replace the hard float instructions with soft-float calls. Is this a known
issue, am I doing something wrong, etc.?

Maybe the Sparc back-end is not able (or willing) to transform the
instructions into library calls. The ARM back-end certainly does.

Is there a reason many of the backend targets will not generate the library
call? Is there some way to fix this?

It may be that they never found it relevant? Or that your options is
not correctly propagated (as Asiri commented).

Looking at X86ISelLowering.cpp, there aren't that many calls to
setLibcallName(), which there are zillions for ARM. The Sparc back-end
has more than the X86, but mostly to round numbers and convert from FP
to Int and vice-versa, so I doubt it'll ever call a library function
to multiply or divide floating points.

If that's the only problem, the way to fix this is to repeat the
pattern in the ARM back-end, and add *all* library call hooks and make
sure they're called when -msoft-float is specified. Also, if you do
so, please add as many tests as necessary to make sure both soft and
hard float are covered correctly.

cheers,
--renato