> >> 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 like >> this. >> 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. It also assumes the result of expansion are of legal types. 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. It's not done simply because there isn't a need for it right now. :-) Evan> > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> 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
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. Evan> > -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