[LLVMdev] Soft-float

[Roman Levenstein]

> >> 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.
> >
> > Yes, this should be fine.
> >
> >>   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 likethis.
> >>   I'm wondering, how easy or difficult would it be to support such
> a  mapping to any integer type?
> >
> > It should be transparently handled by the framework.  Basically,
> you'd
> > get:
> >
> > f32 -> f64 -> i64 -> 2x i32 -> 4x i16
> >
> > If you don't add a register class for i32 or i64, but you do have  
> > one for i16, legalize will already 'expand' them for you.
> >
> 
> This will probably require a slightly more extensive patch to  
> legalizer. The current mechanism assumes either 1->1 or 1->2  
> expansion. 

Exactly. This is what I meant with "more chellenging";) It is assumed
at several places that 1->1 or 2->2 expanstions are taking place. A
generic case is not handled yet.

> It also assumes the result of expansion are of legal  
> types. 

Yes. And this is also a reason why it is not too obvious how to handle
f32->f64 promotion and later f64->i64 expansion on targets that support
only f64 soft-floats. 

Chris Lattner wrote:
>That would be recursively expanded to i64, then to 2x i32 if needed.

I tried to set getTypeToTransformTo(f32) to return f64, even when f64
is illegal type. But this recursive expansion does not take place with
the current legalizer implementation. Currently, it is assumed that the
result of  getTypeToTransformTo() is a legal type. For example,
CreateRegForValue tries to create a register of such a promoted type
and fails in the above mentioned case.
 

Evan wrote:
> That means, you will have to either 1) modify ExpandOp() to  
> handle cases which need to be recursively expanded or 2) modify it to
 
> return a vector of SDOperand's. Solution one is what I would pursue. 

Agreed. I also feel that some sort of recursive expansion is required. 

I also have a feeling that getTypeToTransformTo(MVT::ValueType) should
probably also recurse until it finds a type T where
getTypeToTransformTo(T) = T, i.e. it finds a legal type. This would
almost solve the issue with f32->f64 promotion where both FP types are
illegal. The only concern here is that in this case
getTypeToTransformTo(MVT::f32) would return MVT::i64 and therefore the
information about the fact that it should first be promoted to f64 is
lost. The problem is that getTypeToTransformTo() is used for two
"different" goals: to tell which type to use for register mapping and
to tell which type to use for promotions/expansions for the sake of
"type system correctness". May be it would even make sense to have two
different mappings because of this? One mapping will be used for
allocation of virtual registers and the like and would always return a
legal type and the other will be used just as getTypeToTransformTo() in
LegalizeOp(), ExpandOp() and PromoteOp() and can return also illegal
types? 
 
> It's not done simply because there isn't a need for it right now. :-)

Since I have this need, I'll try to find a solution for this issue and
to provide a patch.

-Roman

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