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

[Chandler Carruth via cfe-dev]

A couple of points:

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.

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.

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*.

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.


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.

On Fri, May 13, 2016 at 7:32 PM C Bergström <cfe-dev at lists.llvm.org> wrote:

> This old discussion may cover some of this as well? I also thought I
> remember something more recent around this..
>
> http://clang-developers.42468.n3.nabble.com/PROPOSAL-Reintroduce-guards-for-Intel-intrinsic-headers-td4046979.html
>
> On Sat, May 14, 2016 at 8:59 AM, Sean Silva via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > Sorry if this is a stupid question, but do the windows intrinsic headers
> > actually contain the same contents as clang's? (e.g. maybe the windows
> ones
> > don't cover all the ISA's that clang's do).
> >
> > -- Sean Silva
> >
> > On Thu, May 12, 2016 at 9:16 AM, Nico Weber via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> >>
> >> 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
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160514/5f34fbdf/attachment.html>