<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div class="moz-cite-prefix">On 5/15/20 3:18 PM, Keane, Erich wrote:<br>
</div>
<blockquote type="cite" cite="mid:SN6PR11MB2943BDEEF60DCC2F565EFED2F0BD0@SN6PR11MB2943.namprd11.prod.outlook.com">
<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]-->
<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.</p>
</div>
</blockquote>
Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed
 and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.<br>
<br>
<blockquote type="cite" cite="mid:SN6PR11MB2943BDEEF60DCC2F565EFED2F0BD0@SN6PR11MB2943.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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 <a class="moz-txt-link-rfc2396E" href="mailto:Simon.Moll@EMEA.NEC.COM">
<Simon.Moll@EMEA.NEC.COM></a> <br>
<b>Sent:</b> Friday, May 15, 2020 6:14 AM<br>
<b>To:</b> Keane, Erich <a class="moz-txt-link-rfc2396E" href="mailto:erich.keane@intel.com">
<erich.keane@intel.com></a>; Craig Topper <a class="moz-txt-link-rfc2396E" href="mailto:craig.topper@gmail.com">
<craig.topper@gmail.com></a><br>
<b>Cc:</b> Clang Dev <a class="moz-txt-link-rfc2396E" href="mailto:cfe-dev@lists.llvm.org">
<cfe-dev@lists.llvm.org></a>; MARUKAWA KAZUSHI <a class="moz-txt-link-rfc2396E" href="mailto:marukawa@nec.com">
<marukawa@nec.com></a>; ISHIZAKA KAZUHISA <a class="moz-txt-link-rfc2396E" href="mailto:ishizaka@nec.com">
<ishizaka@nec.com></a>; Erich Focht <a class="moz-txt-link-rfc2396E" 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>
</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" moz-do-not-send="true">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" moz-do-not-send="true">
<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" moz-do-not-send="true">
<erich.keane@intel.com></a><br>
<b>Cc:</b> Simon Moll <a href="mailto:Simon.Moll@emea.nec.com" moz-do-not-send="true">
<Simon.Moll@emea.nec.com></a>; Clang Dev <a href="mailto:cfe-dev@lists.llvm.org" moz-do-not-send="true">
<cfe-dev@lists.llvm.org></a>; MARUKAWA KAZUSHI <a href="mailto:marukawa@nec.com" moz-do-not-send="true">
<marukawa@nec.com></a>; ISHIZAKA KAZUHISA <a href="mailto:ishizaka@nec.com" moz-do-not-send="true">
<ishizaka@nec.com></a>; Erich Focht <a href="mailto:Erich.Focht@emea.nec.com" moz-do-not-send="true">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">erich.keane@intel.com</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>><br>
Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank" moz-do-not-send="true">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA <<a href="mailto:ishizaka@nec.com" target="_blank" moz-do-not-send="true">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">erich.keane@intel.com</a>>; Clang Dev
<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>><br>
> Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank" moz-do-not-send="true">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA
<br>
> <<a href="mailto:ishizaka@nec.com" target="_blank" moz-do-not-send="true">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">
cfe-dev@lists.llvm.org</a><br>
>> Cc: MARUKAWA KAZUSHI <<a href="mailto:marukawa@nec.com" target="_blank" moz-do-not-send="true">marukawa@nec.com</a>>; ISHIZAKA KAZUHISA
<br>
>> <<a href="mailto:ishizaka@nec.com" target="_blank" moz-do-not-send="true">ishizaka@nec.com</a>>; Erich Focht <<a href="mailto:Erich.Focht@EMEA.NEC.COM" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">
cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" moz-do-not-send="true">
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" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" moz-do-not-send="true">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>
</blockquote>
<br>
</body>
</html>