simoll added a comment. In D81083#2237284 <https://reviews.llvm.org/D81083#2237284>, @rsmith wrote:
> Thanks for dropping by! > 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. Whichever solution is going to land in Clang, we will end up in the situation that Clang supports bool vectors and GCC does not. Any code that uses this feature and is supposed to compile with GCC will need some `#ifdef` guard. This is why i am not too worried about (ab-)using the vector_size attribute for this. > 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. I agree that the vector_size syntax for bool vectors raises some expectations on the behavior of the bool vector. However, i see this more as an issue of proper documentation. The moment somebody uses vector_size attributes they know they are deep in compiler-extension land and far from standard C/C++ semantics. Now about the vector representation issues in Clang and how we could make this work for bool vectors: earlier, i suggested that we could introduce a Clang-internal `Bit` datatype that can only be used as a vector element type. By doing so, we wouldn't violate the invariant that `bits(vector) == size_of_vector * bits(element_type)`. > 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? I am open to a different syntax, if piggy backing on the vector_size syntax is the main point of contention. Up to now, the plan was to have vector_size bool now and work on a proper bool vector type to replace it. 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
