On Sun, 28 Mar 2010, áÒÔÅÍ ûÉÎËÁÒÏ× wrote: > It would be much easier for the programmer to use an abstract layer to > implement a vectorized code. A compiler should deal with the portability > issues > dispatching the code from the abstract layer to the particular architecture. > My
The generic vector types (used with the vector_size attribute) could be seen as the beginnings of such an abstract layer. So you might look at what isn't supported readily with such types at present. Note that patches have been submitted but not committed for some features (e.g. subscripting vectors like arrays) that would need pushing through into GCC. Then you could look at related extensions in other implementations or related languages (e.g. OpenCL) that might be useful for GNU C and C++ generic vectors. What vector instructions are there that cannot be effectively represented using generic vectors (supposing that you add the ability to subscript them, which helps describe a lot of operations using compound literals)? They might need further extensions. Are there instructions that can be effectively represented but where the generic representation in C source does not end up generating the right instructions? If so, you could improve the compiler so that given generic C+vectors source, and generic RTL patterns for the instruction, it ends up generating that instruction. One subset of the problem you could look at would be saturating operations - both for scalars and for vectors. For some such operations, built-in functions might help. Some can be written in generic C, but the compiler won't detect them and generate saturating instructions. See a paper of Bik, Girkar, Grey and Tian <http://saluc.engr.uconn.edu/refs/compiler/bik02idioms.pdf> regarding how to detect saturating operations. There are generic RTL codes for some saturating operations - but they will only ever be generated from target-specific built-in functions at present. -- Joseph S. Myers jos...@codesourcery.com
