llvm dev - May 2013 - [LLVMdev] Help with setting up a software-float supported architecture target

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

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.