simoll added a comment. In D88905#3375676 <https://reviews.llvm.org/D88905#3375676>, @aaron.ballman wrote:
> In D88905#3362347 <https://reviews.llvm.org/D88905#3362347>, @kaz7 wrote: > >> At the beginning, this implementation extends `vector_type` attribute which >> is GCC's attribute. So, this may cause future conflicts with GCC when they >> extend it. But, now this patch uses it's own `ext_vector_type` attribute. >> So, basically this modification is safe against to the C/C++ future >> extension and the GCC future extension, in my honest opinion. >> >> Is it OK to accept this patch? Or is there anything we need to consider? I >> understand that this is a language extension, so it not easy to say OK... >> But, this patch spent 1 year and a half almost. > > At a minimum, I think the patch needs to be rebased onto the current trunk. > However, I don't know of a reason why this patch cannot proceed. It's great to get feedback on this patch! I am rebasing right now. > I'd be curious whether the codegen for ext_vector_type of N bools is the same > as for N `unsigned _BitInt(1)` (naively, I'd expect them to be equivalent). bool vectors are for `<n x i1>`-typed masks in predicated SIMD code - _BitInt is for `iN` integer arithmetic. For either type, the memory representation is packed bits with possible differences in alignment, padding. So, the difference is in the intended usage and what kind of execution units/operands we expect to live the data near by. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88905/new/ https://reviews.llvm.org/D88905 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
