[LLVMdev] Ideas for representing vector gather/scatter and masks in LLVM IR

[Mark Leone]

Good contribution, thanks. I've read the thread but don't have much  
insight. Dan's suggestion sounds plausible, but not especially elegant.

- Mark


On Aug 7, 2008, at 6:13 PM, "Tim Foley" <tim.foley.is at gmail.com> wrote:

> This thread is already churning, so I apologize if by being late to  
> the party I have missed important information.
>
> The "apply_mask" approach is very familiar to me, in that I spent a  
> lot of time thinking about how masking could be added pervasively to  
> LLVM without disrupting the currently nice property that most of the  
> standard arithmetic instructions are "overloaded" to work on all  
> types.
>
> The space of options that I saw available (and please don't judge  
> these options just yet, I am well aware that some of them are  
> abhorrent):
>
> 1 - Make masking explicit and change every potentially side- 
> effecting operation to include an i1 mask in the scalar case and i1  
> vector mask in the vector case.
> 2 - Add specialized masked versions of these operations (distinct  
> from the unmasked versions) either as intrinsics or new instructions
> 3 - Add an implicit mask that all vector operations occur "under"  
> along with operations to set/get (or push/pop) this mask.
> 4 - Like 3 but add some notion of a "vector branch" - that is a  
> conditional branch on a vector of i1 values instead of a single i1,  
> which would implicitly do "the right thing" for masking.
> 5 - Add a new type for "partial" vectors that combines a vector and  
> same-sized mask. Operations overloaded for normal vectors would also  
> work on partial vectors (and not operate on "missing" elements), and  
> would produce partial results.
>
> 1 and 2 are the more-or-less straightforward approaches being  
> considered, and involve either plumbing through new operations, or  
> new semantics for old operations. There is nontrivial (I expect) but  
> straightforward (again, I expect) work involved in either. The rest  
> of the options try to avoid some or all of that work and/or provide  
> niceties for end users at the expense of being "clever".
>
> Options 3 and 4 are almost certainly outside of the realm of what  
> LLVM should consider. One of the best things about SSA is how  
> explicit it makes dependencies, so adding any kind of implicit mask  
> that is carried behind people's backs is really scary.
>
> Option 5 is (to my understanding) equivalent to this whole  
> "apply_mask" approach being discussed, although the latter tries to  
> avoid introducing a new type. Even though "apply_mask" doesn't  
> explicitly introduce a new type, there are all kinds of special  
> rules about when and where a value that has been "apply_mask"'d can  
> be used. Adding a type to represent partiality allows these rules to  
> be made explicit as part of type-checking the IR.
>
> Such partial vectors are still fairly non-orthogonal, so it is  
> unclear whether the end-user experience is worth whatever complexity  
> it adds to the IR.
>
> Anyway, that's my breakdown of the situation. I welcome any feedback  
> from those with a better understanding of the consequences of any of  
> these approaches...
>
> - Tim
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev