<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">> 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)).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Simon Moll <Simon.Moll@EMEA.NEC.COM> <br>
<b>Sent:</b> Friday, May 15, 2020 6:14 AM<br>
<b>To:</b> Keane, Erich <erich.keane@intel.com>; Craig Topper <craig.topper@gmail.com><br>
<b>Cc:</b> Clang Dev <cfe-dev@lists.llvm.org>; MARUKAWA KAZUSHI <marukawa@nec.com>; ISHIZAKA KAZUHISA <ishizaka@nec.com>; Erich Focht <Erich.Focht@EMEA.NEC.COM><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Opt-in vector of bool type<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">That's interesting, i wasn't aware of those bug reports.<br>
<br>
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)).<br>
<br>
We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation.
Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.<br>
<br>
- Simon<br>
<br>
<br>
On 5/14/20 6:33 PM, Keane, Erich wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Ah, the result of operator[] should be an LValue, so it should be addressable. Unfortunately, I don’t think we currently implement that correctly (and consider that a bug). See:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="https://godbolt.org/z/Coo8Ai">https://godbolt.org/z/Coo8Ai</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>From:</b> Craig Topper <a href="mailto:craig.topper@gmail.com">
<craig.topper@gmail.com></a> <br>
<b>Sent:</b> Thursday, May 14, 2020 9:17 AM<br>
<b>To:</b> Keane, Erich <a href="mailto:erich.keane@intel.com"><erich.keane@intel.com></a><br>
<b>Cc:</b> Simon Moll <a href="mailto:Simon.Moll@emea.nec.com"><Simon.Moll@emea.nec.com></a>; Clang Dev
<a href="mailto:cfe-dev@lists.llvm.org"><cfe-dev@lists.llvm.org></a>; MARUKAWA KAZUSHI
<a href="mailto:marukawa@nec.com"><marukawa@nec.com></a>; ISHIZAKA KAZUHISA <a href="mailto:ishizaka@nec.com">
<ishizaka@nec.com></a>; Erich Focht <a href="mailto:Erich.Focht@emea.nec.com"><Erich.Focht@emea.nec.com></a><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Opt-in vector of bool type<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The extended vector types also support operator[] which probably assumes the elements are individually addressable?<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">~Craig<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Craig Topper is the one who will know better, he should be along in a few hours.<br>
<br>
-----Original Message-----<br>
From: Simon Moll <<a href="mailto:Simon.Moll@EMEA.NEC.COM" target="_blank">Simon.Moll@EMEA.NEC.COM</a>>
<br>
Sent: Thursday, May 14, 2020 7:36 AM<br>
To: Keane, Erich <<a href="mailto:erich.keane@intel.com" target="_blank">erich.keane@intel.com</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA <<a href="mailto:ishizaka@nec.com" target="_blank">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank">Erich.Focht@EMEA.NEC.COM</a>><br>
Subject: Re: [RFC] Opt-in vector of bool type<br>
<br>
On 5/14/20 4:14 PM, Keane, Erich wrote:<br>
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?<br>
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it. There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and
many of the passes were not handling it correctly. It makes it a huge undertaking.<br>
That's actually a point in favor of making it opt out.<br>
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'<br>
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?<br>
<br>
> -----Original Message-----<br>
> From: Simon Moll <<a href="mailto:Simon.Moll@EMEA.NEC.COM" target="_blank">Simon.Moll@EMEA.NEC.COM</a>><br>
> Sent: Thursday, May 14, 2020 7:09 AM<br>
> To: Keane, Erich <<a href="mailto:erich.keane@intel.com" target="_blank">erich.keane@intel.com</a>>; Clang Dev
<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA
<br>
> <<a href="mailto:ishizaka@nec.com" target="_blank">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank">Erich.Focht@EMEA.NEC.COM</a>><br>
> Subject: Re: [RFC] Opt-in vector of bool type<br>
><br>
> On 5/14/20 3:57 PM, Keane, Erich wrote:<br>
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR. Don't do this, it still has to be i8s, otherwise it causes a number of problems. <br>
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?<br>
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified. However, I'm curious as to why this would be opt-in on a target basis? Are there some targets that wouldn't be able to legalize this?<br>
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation
to scalarize the type for targets that do not support it.<br>
>> -----Original Message-----<br>
>> From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>> On Behalf Of Simon
<br>
>> Moll via cfe-dev<br>
>> Sent: Thursday, May 14, 2020 6:39 AM<br>
>> To: <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA
<br>
>> <<a href="mailto:ishizaka@nec.com" target="_blank">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank">Erich.Focht@EMEA.NEC.COM</a>><br>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type<br>
>><br>
>> Hi,<br>
>><br>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.<br>
>><br>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.<br>
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).<br>
>> We understand the historical reasons for not supporting this (gcc complicance).<br>
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.<br>
>><br>
>> Looking forward to your feedback.<br>
>><br>
>> - Simon<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>