[Bug middle-end/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 --- Comment #9 from Alexander Monakov --- However, we need to carry the original (npot) lane count for vector operations that are unavailable and lowered to scalar operations. This is especially important for integer division, to avoid SIGFPE from inactive lanes. If supporting ext_vector_type is beyond the event horizon for this reason, can we at least have OpenCL-style swizzle accessors for GCC generic vectors? It gives a nice shorthand notation for vector shuffles, e.g. v.zx = v.zyx.yy; (swizzled [sub-]vector can be on the LHS, with the restriction that there are no duplicated lanes in the swizzle mask) This would close a major usability gap w.r.t ext_vector_type.
[Bug middle-end/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 --- Comment #8 from Alexander Monakov --- (In reply to Alexander Monakov from comment #7) > (GLSL and OpenCL C do not have larger vectors, so size 3 is the only > possible non-power-of-two size) Correction: OpenCL has 8- and 16-element vectors, but 3 remains the only non-power-of-two element count. I see that this bug component is set to "middle-end", but as mentioned, extended vectors are padded to a power-of-two size, so is there anything to be done in the middle end? The most of the enabling work seems to be in language front-ends (separately for C and C++ I presume).
[Bug middle-end/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- (In reply to Drea Pinski from comment #6) > The problem with ext_vector_type is we need to support non-power of 2 vector > sizes. That means this is a middle-end change first. We do not need a middle-end change for that. Clang pads ext_vector_type vectors to a power-of-two size (as well as GNU vector_size vectors). A dereference of a pointer-to-vector accesses the padded size. This matches OpenCL C specification: For 3-component vector data types, the size of the data type is 4 * sizeof(component). This means that a 3-component vector data type will be aligned to a 4 * sizeof(component) boundary. The vload3 and vstore3 built-in functions can be used to read and write, respectively, 3-component vector data types from an array of packed scalar data type. (GLSL and OpenCL C do not have larger vectors, so size 3 is the only possible non-power-of-two size)
[Bug middle-end/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end --- Comment #6 from Andrew Pinski --- The problem with ext_vector_type is we need to support non-power of 2 vector sizes. That means this is a middle-end change first.
