[RFC] optabs and tree-codes for vector operations

[Devang Patel]

On Aug 18, 2004, at 1:58 PM, James E Wilson wrote:

> On Wed, 2004-08-18 at 12:11, Devang Patel wrote:
>> One question : How to express vector operations in C that corresponds
>> to RTL vec_select and vec_merge operations? In Altivec, people can use
>> vec_sel() and vec_merge[h,l](), but I do not know how to express them
>> without Altivec syntax.
>
> It isn't clear to me that we need C syntax for this stuff.  Different
> targets will support different vector features, and if we add C syntax
> for things that Altivec supports, then that might encourage people to
> write code that is spectacularly bad for other targets like mips.
> Meanwhile, using builtin functions seems to work fine for now.

I do not want to add C syntax. I just wanted to understand how they 
works without Altivec syntax. And answer is builtin functions.

> Eventually we will have auto-vectorizer support, and then there is even
> less of a need for C syntax for some of this stuff, unless perhaps we
> need it in support of the vectorizer.  But in that case, we need
> experience with the vectorizer first before we can determine what C
> syntax extensions would be useful.
>
> If we are adding C syntax extensions, then I start with simpler
> operations like extracting one element of a vector, or replacing one
> element of a vector.  I see lots of code using unions to do this.  This
> code could be more efficient if we have a C syntax that directly
> translated into the existing vec_extract<mode>/vec_set<mode> named
> patterns.
>
>> We are following Altivec PIM vocabulary. As you say, vec_sel()
>> operation is represented by vec_merge. I agree it is confusing. Do we
>> have an option to rename existing RTL opertors to match Altivec PIM
>> vocabulary ?
>
> There aren't very many targets using the vector support as yet, so it
> wouldn't be too hard to rename stuff.  There is the question of whether
> standardizing on the Altivec PIM terminology is the right choice.  It 
> is
> convenient for Apple and IBM, but it may not be convenient for others.
> I don't know if anyone has conflicting terminology though.  The Altivec
> PIM is well documented, so on that grounds it would make a nice
> terminology reference.  The x86 vector support was the first one to go
> in.  Maybe there is some relationship between the current terminology
> and the x86 MMX/SSE instruction sets.  I don't have a manual handy to
> check.
>
> If we are changing stuff, then maybe we can split vec_select into two
> different operations.  Currently it can be either an extraction or a
> shuffle, depending on whether the mode of the vec_select matches the
> mode of the operands.  This really should be two different operators.
>
> So we could create a vec_extract RTL operation for one meaning of
> vec_select.

OK.

>   We could rename vec_merge to vec_select.

OK.

>  Then add some
> unnamed merge/shuffle operation to replace the other meaning of
> vec_select, hopefully defining it in a way that avoids confusion about
> canonical forms.

OK.

Thanks,
-
Devang