[cfe-dev] The intrinsics headers (especially avx512) are too big. What to do about it?

[Nico Weber via cfe-dev]

Hi,

on Windows, C++ system headers like e.g. <string> end up pulling in
intrin.h. clang's intrinsic headers are very large.

If you take a cc file containing just `#include <string>` and run that
through the preprocessor with `cl /P test.cc` and `clang-cl /P test.cc`,
the test.I file generated by clang-cl is 1.7MB while the one created by
cl.exe is 0.7MB. This is solely due to clang's intrin.h expanding to way
more stuff.

The biggest offenders
are avx512vlintrin.h, avx512fintrin.h, avx512vlbwintrin.h which add up to
657kB already. Before r239883, we only included avx headers if __AVX512F__
etc was defined. This is currently never the case in practice. Later
(r243394 r243402 r243406 and more), the avx headers got much bigger.

Parsing all this code takes time -- removing the avx512 includes from
immintrin.h locally makes compiling a file containing just the <string>
header 0.25s faster (!), and building all of v8 gets 6% faster, just from
not including the avx512 headers.

What can we do about this? Since avx512 is new, maybe they could be not
part of immintrin.h? Or we could re-introduce

  #if !__has_feature(modules) && defined(__AVX512BW__)

include guards in immintrin.h. This would give us a speed win immediately
without drawbacks as far as I can see, but in a few years when people start
compiling with /arch:avx512 that'd go away again. (Then again, by then,
modules are hopefully commonly available. cl.exe doesn't have an
/arch:avx512 switch yet, so this is probably several years away from
happening.)

Comments? Is it feasible to require that people who want to use avx512
include a new header instead of immintrin.h? Else, does anyone have a
better idea other than reintroducing the #ifdefs, augmented with the module
check?

Thanks,
Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160512/8308fbc2/attachment.html>