<div dir="ltr">So have clang magically emit the generated code based on the intrinsic header? That'll be a lot of typing, but ultimately shouldn't be terrible. You'll effectively turn the _mm_ interface into __builtin as far as automatic recognition etc and I'm not sure we'd want to do that sort of thing.<div><br></div><div>-eric</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 14, 2016 at 6:43 AM Demikhovsky, Elena via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><a name="m_8737318308697110693__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We are still trying to find a suitable solution.<u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Keeping declarations only inside header files will save compile time.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">In this case the implementation will be hidden inside clang.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Can somebody help me to estimate impact and complexity of this solution?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thank you.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<u></u><span style="font-family:"Calibri",sans-serif;color:#2f5496"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><b><i><span style="color:#2f5496"> Elena<u></u><u></u></span></i></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a name="m_8737318308697110693______replyseparator"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <a href="mailto:thakis@google.com" target="_blank">thakis@google.com</a> [mailto:<a href="mailto:thakis@google.com" target="_blank">thakis@google.com</a>]
<b>On Behalf Of </b>Nico Weber<br>
<b>Sent:</b> Tuesday, June 14, 2016 15:50<br>
<b>To:</b> Demikhovsky, Elena <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>><br>
<b>Cc:</b> Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>; Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>>; cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; Badouh, Asaf <<a href="mailto:asaf.badouh@intel.com" target="_blank">asaf.badouh@intel.com</a>>; Zuckerman, Michael <<a href="mailto:michael.zuckerman@intel.com" target="_blank">michael.zuckerman@intel.com</a>>; David Majnemer <<a href="mailto:majnemer@google.com" target="_blank">majnemer@google.com</a>>; Chandler Carruth (<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>)
<<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [cfe-dev] The intrinsics headers (especially avx512) are too big. What to do about it?<u></u><u></u></span></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, May 17, 2016 at 3:49 PM, Demikhovsky, Elena <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>> wrote:<u></u><u></u></p></div></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"> >Indeed. It is not clear to me, however, that this situation is desirable. We<br>
>had a general policy that our intrinsics headers should generate generic IR<br>
>whenever possible, and if we've strayed from that, we should discuss that<br>
>first.<br>
<br>
Let's take a look at this intrinsic:<br>
<br>
static __inline__ __m512i __DEFAULT_FN_ATTRS<br>
_mm512_mask_add_epi64 (__m512i __W, __mmask8 __U, __m512i __A, __m512i __B)<br>
{<br>
return (__m512i) __builtin_ia32_paddq512_mask ((__v8di) __A,<br>
(__v8di) __B,<br>
(__v8di) __W,<br>
(__mmask8) __U);<br>
}<br>
<br>
The IR that should be generated:<br>
%C = add <8 x double> %B, %A<br>
%res = select <8 x i1> %mask, <8 x double> %C, %W<br>
<br>
If we parse __builtin_ia32_paddq512_mask in CGBuiltin.cpp and generate IR there, will it help?<br>
<br>
(Please do not consider my question as a general Intel solution. I just want to understand the problem.)<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
The bit I care most about is that adding `#include <intrin.h>` shouldn't add megabytes of stuff to my translation unit.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Hve you discussed making immintrin.h more modular? It looks like many more avx512 builtins keep landing, making this problem bigger and bigger. It'd be good if I only had to pay for this if I explicitly included an avx512.h, and even then
it'd be nice if that wasn't one huge header, but several smaller ones, so I only have to pay compile time for the bits I need.<u></u><u></u></p>
</div>
</div></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><div></div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p></div><div lang="EN-US" link="blue" vlink="purple">
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></div><div lang="EN-US" link="blue" vlink="purple"></div>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>