aaron.ballman added a comment. In D88905#3378933 <https://reviews.llvm.org/D88905#3378933>, @simoll wrote:
> 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. Okay, that sounds like what I'd hoped for, thank you! 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
