<div dir="ltr">A couple of points:<div><br></div><div>1) Definitely agree with Hal that these intrinsics really shouldn't be mapping to builtins. This is something I'm pretty frustrated about the direction of AVX-512 support in Clang and LLVM. We really need generic vector IR to lower cleanly into these instructions.</div><div><br></div><div>2) Reid, you specifically advocated for not having the set of intrinsics available based on particular feature sets. ;] But I agree there seems to be a scalability problem here.</div><div><br></div><div>3) I think a lot of the scalability problem is that very basic, non-vector code patterns, require Intrin.h on Windows and pull in *ALL* the vector intrinsics. =/ It'd be really good to try to fix *that*.</div><div><br></div><div>4) AVX-512 has made this *incredibly* worse than any previous ISA extension. It used to be we had the product of (operation * operand-type) intrinsics. This is already pretty bad. Now we have (operation * operand-type * 4) because we have 4 masking variants. So it seems Intel has just made a really unfortunate API choice by forcing every permutation of these things to get a different name and thus a different intrinsic in a  header file. =/ And sadly that too is probably too late to walk back.</div><div><br></div><div><br></div><div>I wonder if we could at least initially address this by providing very limited "builtin" modules for truly builtin headers that don't touch any system headers, and actually *always* use the modules approach for these headers, right out of the box.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 13, 2016 at 7:32 PM C Bergström <<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">This old discussion may cover some of this as well? I also thought I<br>
remember something more recent around this..<br>
<a href="http://clang-developers.42468.n3.nabble.com/PROPOSAL-Reintroduce-guards-for-Intel-intrinsic-headers-td4046979.html" rel="noreferrer" target="_blank">http://clang-developers.42468.n3.nabble.com/PROPOSAL-Reintroduce-guards-for-Intel-intrinsic-headers-td4046979.html</a><br>
<br>
On Sat, May 14, 2016 at 8:59 AM, Sean Silva via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> Sorry if this is a stupid question, but do the windows intrinsic headers<br>
> actually contain the same contents as clang's? (e.g. maybe the windows ones<br>
> don't cover all the ISA's that clang's do).<br>
><br>
> -- Sean Silva<br>
><br>
> On Thu, May 12, 2016 at 9:16 AM, Nico Weber via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> on Windows, C++ system headers like e.g. <string> end up pulling in<br>
>> intrin.h. clang's intrinsic headers are very large.<br>
>><br>
>> If you take a cc file containing just `#include <string>` and run that<br>
>> through the preprocessor with `cl /P test.cc` and `clang-cl /P test.cc`, the<br>
>> test.I file generated by clang-cl is 1.7MB while the one created by cl.exe<br>
>> is 0.7MB. This is solely due to clang's intrin.h expanding to way more<br>
>> stuff.<br>
>><br>
>> The biggest offenders are avx512vlintrin.h, avx512fintrin.h,<br>
>> avx512vlbwintrin.h which add up to 657kB already. Before r239883, we only<br>
>> included avx headers if __AVX512F__ etc was defined. This is currently never<br>
>> the case in practice. Later (r243394 r243402 r243406 and more), the avx<br>
>> headers got much bigger.<br>
>><br>
>> Parsing all this code takes time -- removing the avx512 includes from<br>
>> immintrin.h locally makes compiling a file containing just the <string><br>
>> header 0.25s faster (!), and building all of v8 gets 6% faster, just from<br>
>> not including the avx512 headers.<br>
>><br>
>> What can we do about this? Since avx512 is new, maybe they could be not<br>
>> part of immintrin.h? Or we could re-introduce<br>
>><br>
>>   #if !__has_feature(modules) && defined(__AVX512BW__)<br>
>><br>
>> include guards in immintrin.h. This would give us a speed win immediately<br>
>> without drawbacks as far as I can see, but in a few years when people start<br>
>> compiling with /arch:avx512 that'd go away again. (Then again, by then,<br>
>> modules are hopefully commonly available. cl.exe doesn't have an<br>
>> /arch:avx512 switch yet, so this is probably several years away from<br>
>> happening.)<br>
>><br>
>> Comments? Is it feasible to require that people who want to use avx512<br>
>> include a new header instead of immintrin.h? Else, does anyone have a better<br>
>> idea other than reintroducing the #ifdefs, augmented with the module check?<br>
>><br>
>> Thanks,<br>
>> Nico<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="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>
>><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="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>
><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="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>