Help with setting up a software-float supported architecture target

Project Infrastructure LLVM Dev List Archives
1

For a LLVM code target, I am developing a software-supported floating-point engine. I’ve come into a few issues in which the DAG conversion is

Can anyone help with:

I have some C code test like:

float x;
printf(“%f”, x);

which clang coverts to:

%0 = load float* @x, align 4
%conv = fpext float %0 to double

The issue is for simple Float to Double extension, the DAGCombiner.cpp
DAGCombiner::visitFP_EXTEND(SDNode *N) is making a decision to do a load extension, and it translates into doing a simple double load. But problem is that my target can’t simple load 8 bytes from the 4 byte float memory location to do a conversion to double.

But what I need is for the DAG conversion to respect that the fpext should be converted into a “call” to a software routine, specifically RTLIB

I have the code set for “custom” ISD:FP_EXTEND to make the subroutine call, but the FP_EXTEND never gets invoked because the DAG conversion changes this to a load extension.

I have seen a few things about TLI:isLoadExtLegal, that I need to track down.

But I wanted to check on the best way to make sure a set of floating-point concepts are left as calls for my target. Is there a way to explain to the DAG conversion system prior to the target lowering, that it should above some target-specific.

For example, since I have a software-only float architecture, how is it best supported for LLVM compilation to have the DAG system know that the operations types need to remain as float calls?

Thanks for any pointers and help.

Dan

2

Hi Dan,

For example, since I have a software-only float architecture, how is it best
supported for LLVM compilation to have the DAG system know that the
operations types need to remain as float calls?

I think in most architectures this would be handled by not marking any
floating-point type as legal in XXXISelLowering.cpp. Look for:

    addRegisterClass(MVT::fXXX, ...);

calls and remove them. If you've done that then type legalization
should convert all floating-point operations into library calls
automatically before the DAG combiner gets involved. The DAG combiner
shouldn't undo any of this.

If you *really* need floating types to be legal for some reason, then
you're on the right track, and "setLoadExtAction" will be what
controls the combiner in this particular case. But there may be other
places you've got to help things along. For example the AArch64
backend is in that position with fp128 and has to emit the RTLIB calls
itself to some degree.

As always, see how other backends do it.

Cheers.

Tim.