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