[LLVMdev] Soft-float

Evan Cheng evan.cheng at apple.com
Wed Dec 20 14:53:26 PST 2006

On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote:

>> 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.

All of the issues can be solved by adding the logic to recursively  
expand operands. They shouldn't be too complicated.

> 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?

No need to change getTypeToTransformTo(). There is a getTypeToExpandTo 
() that is expand the type recursively until it find a legal type.

>> 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.

Great! There are a few spots where ExpandOp() are called recursively.  
It would be nice to remove those and use the general expansion  
facility instead.


> -Roman
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list