[LLVMdev] Soft-float

[Roman Levenstein]

Hi,

I tried out the new soft-float support from the mainline. 

Overall, it looks very nice and pretty clean. It is now extremely easy
to add the soft-float support for your target. Just do not call
addRegisterClass() for your FP types and they will be expanded into
libcalls.

But there are several minor things that would be still nice to have:

a) It is not possible to express that:
   - f32 and f64 are both illegal and therefore are mapped to integers
   - but only f64 is emulated on the target and there are no f32
arithmetic libcalls available (which is the case on our target)  

To make it possible, f32 should be always promoted first to f64 and
then an f64 operation should be applied.

I see a small problem here with the current code, since f32 should be
promoted to the illegal type f64. It might require some special-case
handling eventually. For example, what should be the result
getTypeToTransformTo(f32)? On the one hand, it is f64. On the other
hand it is illegal. 
           
b) LLVM currently uses hard-wired library function names for           
  FP libcalls (and ALL other libcalls as well). It would be nice if
they would be customizable, since some targets (e.g. some embedded
systems) have some existing naming conventions that are to be followed
and cannot be changed. For example, on our embedded target all libcalls
for soft-float and some integer operations have very target-specific
names for historical reasons.

TargetLowering class specific for a target could be extended to handle
that and this would require only minor changes. 
              
c) LLVM libcalls currently pass their parameters on stack. But on some
embedded systems FP support routines expect parameters on specific
registers.             
   At the moment, SelectionDAGLegalize::ExpandLibCall() explicitly uses
CallingConv::C, but it could be made customizable by introducing a
special libcall calling convention or even better by allowing the
target specific lowering of libcalls. Actually it can be combined with
the solution for (b). In this case target-specific lowering can take
care about names of libcalls and also how they handle their parameters
and return values.
              
d) Would it be possible with current implementation of soft-float
support to map f32/f64 to integer types smaller than i32, e.g. to i16?
I have the impression that it is not necessarily the case, since it
would require that f64 is split into 4 parts. 
   This question is more about a theoretical possibility. At the moment
my embedded target supports i32 registers. But some embedded systems
are still only 16bit, which means that they would need something like
this.
   I'm wondering, how easy or difficult would it be to support such a
mapping to any integer type?

My impression is that (b) and (c) are very easy to implement, but (a)
and (d) could be more chellenging.

Evan, I guess you are the most qualified person to judge about this,
since you implemented the new soft-float support.

What do you think about these extension proposals? 

-Roman  


--- Roman Levenstein <romixlev at gmail.com> wrote:
> > Date: Tue, 19 Dec 2006 22:13:08 +0100
> From: Roman Levenstein <romixlev at yahoo.com>
> To: Chris Lattner <sabre at nondot.org>
> Subject: Re: Soft-float
> 
> Hi Chris,
> 
> > BTW, in mainline CVS, the LLVM legalizer now supports expanding
> > floating  point types to integer types and inserting GCC-style 
> > libcalls for soft-float.  Please ask on the mailing list if you 
> > have any questions,
> 
> Oh, nice to know! Thanks for this info! Actually didn't have too much
> 
> time for LLVM hacking recently, since I had a lot of business trips.
> But 
> just last week I got a working version of soft-floats using both 
> approaches: a simple post code selection pass and my legalizer-based 
> solution. The second one was much more complex to implement, noy very
> "clean" and affected many different places of the CodeGen. I haven't 
> done any performance comparisions yet to see if legalizer-based
> approach really brings any significant wins.
> 
> I'll have a look at the mainline and compare it to my implementation
> to see the differences between them. I'll also try to formulate some 
> questions and report about my experiences while changing the LLVM 
> legalizer to support it.
> 
> -Roman
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com