simoll added inline comments.
================ Comment at: clang/docs/LanguageExtensions.rst:473 +architectures. The size parameter of a boolean vector type is the number of +bits in the vector (for all non-bool vectors, the number refers to the number +of bytes in the vector). ---------------- rsandifo-arm wrote: > simoll wrote: > > lenary wrote: > > > It would be nice if this aside about non-bool vectors was more > > > prominently displayed - it's something I hadn't realised before. > > Yep. that caught me by surprise too. I'll move that sentence to the > > paragraph about GCC vectors above. > Sorry for the extremely late comment. Like @lenary I hadn't thought about > this. I'd assumed that the vector woiuld still be a multiple of 8 bits in > size, but I agree that's probably too restrictive to be the only option > available. > > In that case, would it make sense to add a separate attribute instead? I > think it's too surprising to change the units of the existing attribute based > on the element type. Perhaps we should even make it take two parameters: the > total number of elements, and the number of bits per element. That might be > more natural for some AVX and SVE combinations. We wouldn't need to supporrt > all combinations from the outset, it's just a question whether we should make > the syntax general enough to support it in future. > > Perhaps we could do both: support `vector_size` for `bool` using byte sizes > (and not allowing subbyte vector lengths), and add a new, more general > attribute that allows subbyte lengths and explicit subbyte element sizes. > In that case, would it make sense to add a separate attribute instead? I > think it's too surprising to change the units of the existing attribute based > on the element type. Perhaps we should even make it take two parameters: the > total number of elements, and the number of bits per element. That might be > more natural for some AVX and SVE combinations. We wouldn't need to supporrt > all combinations from the outset, it's just a question whether we should make > the syntax general enough to support it in future. I guess adding a new attribute makes sense mid to long term. For now, i'd want something that just does the job... ie, what is proposed here. We should absolutely document the semantics of vector_size properly.. it already is counterintuitive (broken, if you ask me). > Perhaps we could do both: support vector_size for bool using byte sizes (and > not allowing subbyte vector lengths), and add a new, more general attribute > that allows subbyte lengths and explicit subbyte element sizes. Disallowing subbyte bool vectors actually makes this more complicated because these types are produced implicitly by compares of (legal) vector types. Consider this: typedef int int3 __attribute__((vector_size(3 * sizeof(int)))); int3 A = ...; int3 B = ...; auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed value. Regarding your proposal for a separate subbyte element size and subbyte length, that may or may not make sense but it is surely something that should be discussed more broadly with its own proposal. 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
