[LLVMdev] proposal to add MVT::vAny type

[Chris Lattner]

On Aug 8, 2009, at 11:47 PM, Bob Wilson wrote:

> The ARM Neon load, store and shuffle operations that I've been
> implementing recently with LLVM intrinsics do not care about the
> distinction between vectors with i32 and f32 elements -- only the size
> matters.  But, because we have only MVT::fAny and MVT::iAny types,
> I've been having to define separate intrinsics for the operations with
> floating-point vector elements.  It didn't bother me when there were
> only a few intrinsics like this, but now there are more, and I
> realized this weekend that I still need to add more for the load/store
> lane operations.

Hi Bob,

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

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

-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