[LLVMdev] proposal to add MVT::vAny type

[Evan Cheng]

SSE is suffering from the same issue. We end up with a lot of def :  
Pat  patterns. I am not sure whether having vAny will solve it though.  
We don't want to match to any vector type rather any vector type of a  
given size. It would be nice if we can use PatFrag to specify type  
matching code for dagisel.

Evan

On Aug 9, 2009, at 1:41 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote:
>> I really do think that bitcast is the right way to go here.  I ran
>> into a couple of similar problems when bringing up the altivec port.
>> For example, at one time we'd get "all zero vectors" of different
>> MVTs, which would not be CSEd.
>>
>> The fix for this was to be really disciplined about what types to  
>> make
>> things in, and use bitcasts to convert the types when appropriate.
>> For example, the all zeros vector is now only created as a <4 x i32>
>> (IIRC) and bitcasted to the desired type.
>
> Yes, I used that approach, at least to some extent, for Neon.  There
> may be more to do to make sure things are getting CSEd the way we  
> want.
>
>> If this is impacting
>> intrinsics, it seems that the front-end could do a similar thing to
>> canonicalize the intrinsics early.  As you know, we do prefer to have
>> as few intrinsics as possible.
>
> That is exactly what I'm trying to accomplish here (fewer
> intrinsics).  I think I can do it with bitcasts, though.
>
>>
>> Can you describe a bit more about what fAny would do for you, maybe
>> with an example?  I'm sorry that I don't know much at all about
>> neon...
>
> It doesn't do anything fundamental.  It just seems like a better fit.
> Neon has vectors of both integers and floats.  Currently my choices
> for describing the type constraints for a Neon intrinsic are iAny or
> fAny, but those also allow scalars.  vAny would more accurately
> indicate that only vector types are allowed, and it would also avoid
> the need for bitcasting.
>
> It sounds like it is not a popular idea, so I'll let it rest.
>
>>
>> -Chris
>>
>>
>>>
>>> I had been thinking about trying to bitcast my way out of this, but
>>> it
>>> struck me that it would make a lot more sense to have a new  
>>> MVT::vAny
>>> type that TableGen would match to any vector type.  That would more
>>> accurately reflect the type constraints on these intrinsics.
>>>
>>> It seems like since these "*Any" types are confined to TableGen, it
>>> should be pretty easy to add another one.  I looked at the places
>>> using iAny and fAny and they seem pretty easy to extend to handle a
>>> new vAny type.  Does this seem like a good idea?  Any objections?
>>>
>>> I'd like to get the Neon intrinsics finalized before the 2.6  
>>> release,
>>> since it may be harder to change them later.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev