[PATCH] D88905: [Clang] Allow "ext_vector_type" applied to Booleans

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 14 05:12:20 PDT 2022


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



More information about the cfe-commits mailing list