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
> 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
> 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
> 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
> 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
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
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev