[LLVMdev] proposal to add MVT::vAny type

[Bob Wilson]

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