rsmith added a comment. Have you considered using the `ext_vector_type` attribute instead of `vector_size` for this? That would have a couple of advantages:
- It's not a GCC attribute, so there's no risk that GCC would give different meaning to the same syntax (such as using one byte per vector element, which would be the natural meaning for a vector of `bool` as an extension of existing functionality). - `ext_vector_type` takes as an argument a number of elements, not a size in bytes, so you could support vectors of non-multiple-of-8 `bool`s. However, using either an `ext_vector_type` of `bool` or a `vector_size` of `bool` would still seem problematic in a couple of other ways: - Those types always produce a vector whose element type is the specified type; you can form an lvalue denoting the element, the element is always represented the same as the underlying type, and you can pun between a vector of N `T` and an array of N `T`. GCC even permits forming a pointer or reference to a vector element, and you should assume that Clang will eventually support that too. That would not be possible for `bool` if packed as a bit-vector. - You can already perform logical operations between our existing vector types -- for example, comparing two vectors of 4 `int`s. If vectors of `bool` are valid, it would be logical and natural to expect a vector of 4 `bool`s to have some connection to the result of such a comparison, but it won't: the type of a comparison of two vectors of 4 `int`s is a vector of 4 `int`s each of which is either 0 or -1, and we can't convert that to a vector of 4 `bool`s represented as our existing vector types, because such conversions would be interpreted as bitcasts, and we'd reject because the bitwidth of the vectors is different. - Vectors of integer types (such as `bool`) generally support arithmetic operators, which you presumably do not want to support here. - Our existing vector types carry a lot of baggage (for example, lax vector conversions, and the egregious attribute-on-typedef-changes-the-type hack) that we would not want a new type to include. So I think you should seriously consider using a new syntax to form a bit-vector type. It seems to me that an N-bit bit-vector is quite similar to an `_ExtInt(N)`, but without the arithmetic support and with a different expected IR type. Maybe following that syntactic path and adding `_BitVector(N)` syntax would work out better? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81083/new/ https://reviews.llvm.org/D81083 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
