<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:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:799957587;
mso-list-type:hybrid;
mso-list-template-ids:-1214880770 44585902 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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"><span style="color:#1F497D">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">As mentioned in past discussions, the introduction of AVX512 intrinsics had a severe impact on the compile time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The extreme case happens on windows where the mere inclusion of system headers like <string> causes a hit in the compile time of applications that don’t even make use of any intrinsics.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><a href="http://lists.llvm.org/pipermail/cfe-dev/2016-May/048837.html">http://lists.llvm.org/pipermail/cfe-dev/2016-May/048837.html</a>
<br>
<a href="http://lists.llvm.org/pipermail/cfe-dev/2016-June/049460.html">http://lists.llvm.org/pipermail/cfe-dev/2016-June/049460.html</a><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">During these discussions Chandler Carruth indicated that usage of clang modules is probably the best alternative to mitigate this problem:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><a href="http://lists.llvm.org/pipermail/cfe-dev/2016-June/049513.html">http://lists.llvm.org/pipermail/cfe-dev/2016-June/049513.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Based on this feedback, Intel has started working on this proposal. Initial Internal measurements indicated that this direction is promising.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">For example, the compile time of a single translation unit that includes all of the intel intrinsic header files would reduce by 90% starting from the 2nd compilation (by using cached pre-compiled modules). In
general, we saw that compilation of projects that have more than one translation unit that includes x86intrin.h/immintrin.h will get big compile time reductions starting from the 1st compilation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The biggest advantage of this approach is that it scales and would help also applications that do rely on intrinsics and hence will not be able to avoid the compile time overhead.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I (Intel) would like to add a Clang option that enables the modules feature exclusively for the Intel intrinsics header files, and set this option to be turned on by default. This allows clang to cache a pre-compiled
(actually pre-parsed) module of all the headers included by x86intrin.h/immintrin.h, and any following compilation of #include<x86intrin.h>/<immintrin.h> directives will skip the parsing phase and save precious compile time. Since ‘clang modules’ and the regular
‘pre-processor include mechanism’ are not 100% compatible, I started by cleaning some small Intel intrinsics module bugs exposed by this work:
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><a href="https://reviews.llvm.org/D23871">https://reviews.llvm.org/D23871</a>,
<a href="https://reviews.llvm.org/D24825">https://reviews.llvm.org/D24825</a>, <a href="https://reviews.llvm.org/D24752">
https://reviews.llvm.org/D24752</a> (This one is still in review).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I plan to upload the actual patch that adds the option I mentioned above somewhere next week hopefully. Once this patch is uploaded, you could experiment with it and see if it actually mitigates the problem on
your end and provide us with valuable feedback on this direction.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Elad<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><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"> Demikhovsky, Elena
<br>
<b>Sent:</b> Thursday, September 29, 2016 22:20<br>
<b>To:</b> Reid Kleckner <rnk@google.com>; Hans Wennborg <hans@chromium.org>; Blank, Guy <guy.blank@intel.com>; Aboud, Amjad <amjad.aboud@intel.com>; Craig Topper <craig.topper@gmail.com>; Badouh, Asaf <asaf.badouh@intel.com>; Zuckerman, Michael <michael.zuckerman@intel.com>;
Breger, Igor <igor.breger@intel.com><br>
<b>Cc:</b> Nathan Froyd <nfroyd@mozilla.com>; Nico Weber <thakis@chromium.org>; cfe-dev <cfe-dev@lists.llvm.org>; Ouriel, Boaz <boaz.ouriel@intel.com>; Cohen, Elad2 <elad2.cohen@intel.com><br>
<b>Subject:</b> RE: [cfe-dev] clang-cl's <intrin.h>, _tzcnt_u32, and compatibility with MSVC's <intrin.h><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Forwarding your mail to Elad who is working now on intrinsics. Please take into account a possible delay in Elad’s response, we are in local holidays this week.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-family:"Calibri",sans-serif;color:#2F5496"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span dir="LTR"></span><b><i><span style="color:#2F5496"> Elena<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></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="_____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"> Reid Kleckner [<a href="mailto:rnk@google.com">mailto:rnk@google.com</a>]
<br>
<b>Sent:</b> Thursday, September 29, 2016 22:02<br>
<b>To:</b> Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>>; Blank, Guy <<a href="mailto:guy.blank@intel.com">guy.blank@intel.com</a>>; Aboud, Amjad <<a href="mailto:amjad.aboud@intel.com">amjad.aboud@intel.com</a>>; Demikhovsky, Elena
<<a href="mailto:elena.demikhovsky@intel.com">elena.demikhovsky@intel.com</a>>; Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>>; Badouh, Asaf <<a href="mailto:asaf.badouh@intel.com">asaf.badouh@intel.com</a>>; Zuckerman, Michael
<<a href="mailto:michael.zuckerman@intel.com">michael.zuckerman@intel.com</a>>; Breger, Igor <<a href="mailto:igor.breger@intel.com">igor.breger@intel.com</a>><br>
<b>Cc:</b> Nathan Froyd <<a href="mailto:nfroyd@mozilla.com">nfroyd@mozilla.com</a>>; Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>>; cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] clang-cl's <intrin.h>, _tzcnt_u32, and compatibility with MSVC's <intrin.h><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">We've been here before:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><a href="https://llvm.org/bugs/show_bug.cgi?id=25544">https://llvm.org/bugs/show_bug.cgi?id=25544</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=253358">http://llvm.org/viewvc/llvm-project?view=revision&revision=253358</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=556735">https://bugs.chromium.org/p/chromium/issues/detail?id=556735</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">Nico's change to avoid including bmiintrin.h if _MSC_VER is set to reduce compile time brought the problem back.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">Basically, Intel's immintrin.h interface is too big. It's windows.h all over again. It significantly slows down builds of simple projects that include basic STL headers like <string>. Nico
was able to speed up the *overall* build time of Chromium by at least 10% (ask him for specifics) by adding all these '#if !defined(_MSC_VER)' checks to immintrin.h. However, for compatibility, I think we may need intrin.h to include most of that stuff by
default.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">I added a bunch of Intel folks to basically ask the question: Can we please go back to the old days of mmintrin.h, xmmintrin.h, then emmintrin.h?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">If not, we will have to consider adding an evil configuration macro, like WIN32_LEAN_AND_MEAN for windows.h, that opts out of all this extra immintrin.h functionality to speed up compilation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">On Thu, Sep 29, 2016 at 11:04 AM, Hans Wennborg <<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:46.2pt;text-indent:-17.85pt">
On Thu, Sep 29, 2016 at 10:50 AM, Nathan Froyd via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> [While I filed this as <a href="https://llvm.org/bugs/show_bug.cgi?id=30506" target="_blank">
https://llvm.org/bugs/show_bug.cgi?id=30506</a>,<br>
> Paul Robinson suggested in the bug that it might be worth bringing to<br>
> cfe-dev for wider discussion.]<br>
><br>
> Firefox's copy of FFmpeg includes <intrin.h> on MSVC:<br>
><br>
> <a href="https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/libavutil/x86/intmath.h#26" target="_blank">
https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/libavutil/x86/intmath.h#26</a><br>
><br>
> and MSVC's <intrin.h> (after including several other headers) declares<br>
> _tzcnt_u32. clang-cl declares _tzcnt_u32 in <bmiintrin.h>, but<br>
> <bmiintrin.h> is only included from <intrin.h> if an appropriate<br>
> target CPU is detected:<br>
><br>
> <a href="https://github.com/llvm-mirror/clang/blob/master/lib/Headers/immintrin.h#L82" target="_blank">
https://github.com/llvm-mirror/clang/blob/master/lib/Headers/immintrin.h#L82</a><br>
><br>
> even though _tzcnt_u32 (or rather, its underlying implementation<br>
> function, __tzcnt_u32) is explicitly declared to be available<br>
> everywhere:<br>
><br>
> <a href="https://github.com/llvm-mirror/clang/blob/master/lib/Headers/bmiintrin.h#L284" target="_blank">
https://github.com/llvm-mirror/clang/blob/master/lib/Headers/bmiintrin.h#L284</a><br>
><br>
> The net result is that Firefox's copy of FFmpeg doesn't compile with<br>
> clang-cl because of this issue. Upstream has the same code, so I<br>
> assume the same is true there:<br>
><br>
> <a href="https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/intmath.h#L26" target="_blank">
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/intmath.h#L26</a><br>
><br>
> AFAICT, this behavior was changed by only including <bmiitrin.h> if<br>
> __BMI__ is defined in:<br>
><br>
> <a href="http://reviews.llvm.org/D20291" target="_blank">http://reviews.llvm.org/D20291</a><br>
><br>
> with the desirable goal of reducing compile time. But this change<br>
> also broke things like _tzcnt_u32 being available.<br>
><br>
> What is the right thing to do here? Should <bmiintrin.h> be<br>
> unconditionally included, or should something else be done?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt">I think these intrinsics (it's really just tzcnt though?) that are<br>
useful also for non-BMI targets should probably be moved out of the<br>
BMI-specific header.<br>
<br>
+thakis and rnk if they have any thoughts on this.<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:46.2pt;text-indent:-17.85pt"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<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></body>
</html>