[cfe-dev] [RFC] Opt-in vector of bool type
Simon Moll via cfe-dev
cfe-dev at lists.llvm.org
Wed Jun 3 04:46:40 PDT 2020
FYI, the patch for boolean "vector_size" types in Clang, including documentation and implementation, is now on Phabricator:
https://reviews.llvm.org/D81083
- Simon
On 5/18/20 3:15 PM, Simon Moll via cfe-dev wrote:
Ok. So the next step would be an RFC/spec for the C,C++ language semantics this type would have.
What would this spec be based on? Is there any authoritative documentation for 'vector_size' beyond what's in the GCC and Clang docs?
GCC: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
Clang: https://clang.llvm.org/docs/LanguageExtensions.html
If not, i will update the Clang docs and put it on Phabricator for review.
Thanks
- Simon
On 5/15/20 6:01 PM, Keane, Erich via cfe-dev wrote:
I’m not sure, I haven’t experimented with GCC enough to know.
From: Finkel, Hal J. <hfinkel at anl.gov><mailto:hfinkel at anl.gov>
Sent: Friday, May 15, 2020 8:54 AM
To: Richard Sandiford <richard.sandiford at arm.com><mailto:richard.sandiford at arm.com>; Keane, Erich via cfe-dev <cfe-dev at lists.llvm.org><mailto:cfe-dev at lists.llvm.org>; Keane, Erich <erich.keane at intel.com><mailto:erich.keane at intel.com>
Cc: Erich Focht <Erich.Focht at EMEA.NEC.COM><mailto:Erich.Focht at EMEA.NEC.COM>; MARUKAWA KAZUSHI <marukawa at nec.com><mailto:marukawa at nec.com>; ISHIZAKA KAZUHISA <ishizaka at nec.com><mailto:ishizaka at nec.com>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Keane, Erich via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: Friday, May 15, 2020 9:43 AM
To: Richard Sandiford <richard.sandiford at arm.com<mailto:richard.sandiford at arm.com>>; Keane, Erich via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>; MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; ISHIZAKA KAZUHISA <ishizaka at nec.com<mailto:ishizaka at nec.com>>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type
Right, I mentioned that:
> Note we don't allow taking a non-const ref or address of a vector element, but GCC does, though presumably that is something we should fix.
I think that this is another thing that falls into the category of: only if we can define the semantics in a way that makes sense. For example, are the addresses of two adjacent vector elements adjacent? Can you do pointer arithmetic to get from one to the other?
-Hal
-----Original Message-----
From: Richard Sandiford <richard.sandiford at arm.com<mailto:richard.sandiford at arm.com>>
Sent: Friday, May 15, 2020 7:41 AM
To: Keane, Erich via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: Simon Moll <Simon.Moll at EMEA.NEC.COM<mailto:Simon.Moll at EMEA.NEC.COM>>; Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>>; Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; ISHIZAKA KAZUHISA <ishizaka at nec.com<mailto:ishizaka at nec.com>>; Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type
"Keane, Erich via cfe-dev" <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> writes:
>> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).
>
> I don't take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn't individually addressable. Unless you have a way to produce an address for each individual element (which we don't, and is why std::vector<bool> uses a proxy return type), I don't think this fits in the type system.
FWIW, I think taking the address of a vector_size element is already an error in clang. E.g.
-----------------------------------------------------------------
typedef unsigned int vec __attribute__((vector_size(16))); vec v; unsigned int *foo(void) { return &v[1]; }
-----------------------------------------------------------------
gives:
-----------------------------------------------------------------
foo.c:3:34: error: address of vector element requested unsigned int *foo(void) { return &v[1]; }
^~~~~
1 error generated.
-----------------------------------------------------------------
GCC does accept this, but like others have said, I think the natural thing would be to make it an error for bools even if it isn't for other types. The set of operations supported by a vector type is inevitably going to be influenced by the element type.
Definitely agree that the semantics need to be spelled out though. :-)
Thanks,
Richard
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200603/8c324f0a/attachment-0001.html>
More information about the cfe-dev
mailing list