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

Mon Jun 20 09:04:01 PDT 2016

It's already the case that the compiler needs to be in almost-exact-sync
with the intrinsics headers, due to the use of internal builtins functions
which seem to be typically introduced or removed at the same time as
updating the header. I don't think modules would make this any worse than
it is already?

On Mon, Jun 20, 2016 at 6:52 AM, Benyei, Guy via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Modules could be a good solution for this issue, however I’m a bit
> concerned about some technical issues with keeping the modules in sync with
> the Clang compiler.
>
>
>
> Building the actual module files as part of the build system doesn’t seem
> really hard, but still need to think about the location it should be
> installed (with the headers?), and need to make sure, that for any Clang we
> run we can find the suiting module files, or fall back to the headers
> approach.
>
>
>
> We could add the module as some kind of resource to the executable. This
> way it couldn’t get out of sync. I would also add some way to disable this
> optimization entirely.
>
>
>
> What do you think?
>
>
>
> [image: signature]
>
>
>
> *From:* Chandler Carruth [mailto:chandlerc at google.com]
> *Sent:* Thursday, June 16, 2016 00:20
> *To:* Benyei, Guy <guy.benyei at intel.com>; Eric Christopher <
> echristo at gmail.com>; Demikhovsky, Elena <elena.demikhovsky at intel.com>;
> Nico Weber <thakis at chromium.org>; cfe-dev at lists.llvm.org
> *Cc:* David Majnemer <majnemer at google.com>; Badouh, Asaf <
> asaf.badouh at intel.com>; Zuckerman, Michael <michael.zuckerman at intel.com>
>
> *Subject:* Re: [cfe-dev] The intrinsics headers (especially avx512) are
> too big. What to do about it?
>
>
>
> As I said up the thread, I think the *right* way to solve this is with
> modules.
>
>
>
> We have the infrastructure in clang to lazily load things like the
> intrinsics headers in a very efficient way. All we are missing is:
>
> 1) The ability to enable this by default exclusively for the intrinsic
> headers. (or more generally for any subset of the builtin headers where we
> would like this behavior...)
>
> 2) To build the actual module files for the builtin headers (much the way
> we generate some of them) as part of the build system
>
>
>
> So far I've not seen any suggestions that really seem superior to this...
>
>
>
> On Wed, Jun 15, 2016 at 1:23 PM Benyei, Guy via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> I agree, that it’s not desirable thing in Clang, however it seems to me
> the lesser evil.
>
>
>
> The long compilation time will hurt many projects, I’m not sure if it’s
> reasonable even for the ones trying to use AVX intrinsics intentionally.
>
> Another issue is, that the “_mm_” prefixed identifiers are not reserved
> for the compiler - the C99 spec says that identifiers that start with two
> underscores or an underscore and a capital letter are reserved. So, Clang
> should recognize the “_mm_” prefix, check if the right header was indeed
> included, and then try to identify the x86 intrinsic. If this fails, the
> identifier should be considered a standard identifier.
>
>
>
> Of course, there is the case of x86 intrinsics that should be compiled to
> pure LLVM IR, rather than LLVM intrinsic calls. I see two possible
> solutions:
>
>
>
> 1.       Make CGBuiltin.cpp/EmitX86BuiltinExpr generate the IR using the
> IR builder. This approach might be less intuitive, and may become very long
> as we change more and more intrinsics to pure LLVM IR
>
> 2.       Leave the intrinsics implemented in C language in the header,
> rather than making these “_mm_” builtins. Then, again, as we move more and
> more intrinsics to C representation, the header might get big and heavy
> again.
>
>
>
> I think in the short term I would prefer the 2nd solution as for its
> simplicity. Any other ideas to overcome this issue?
>
>
>
> Thanks
>
>      Guy Benyei
>
>
>
>
>
> [image: signature]
>
>
>
> *From:* cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of *Eric
> Christopher via cfe-dev
>
>
> *Sent:* Tuesday, June 14, 2016 23:53
> *To:* Demikhovsky, Elena <elena.demikhovsky at intel.com>; Nico Weber <
> thakis at chromium.org>
>
> *Cc:* cfe-dev <cfe-dev at lists.llvm.org>; David Majnemer <
> majnemer at google.com>; Badouh, Asaf <asaf.badouh at intel.com>; Zuckerman,
> Michael <michael.zuckerman at intel.com>
>
>
> *Subject:* Re: [cfe-dev] The intrinsics headers (especially avx512) are
> too big. What to do about it?
>
>
>
> 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.
>
>
>
> -eric
>
>
>
> On Tue, Jun 14, 2016 at 6:43 AM Demikhovsky, Elena via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> We are still trying to find a suitable solution.
>
> Keeping declarations only inside header files will save compile time.
>
> In this case the implementation will be hidden inside clang.
>
> Can somebody help me to estimate impact and complexity of this solution?
>
>
>
> Thank you.
>
>
>
> -          * Elena*
>
>
>
> *From:* thakis at google.com [mailto:thakis at google.com] *On Behalf Of *Nico
> Weber
> *Sent:* Tuesday, June 14, 2016 15:50
> *To:* Demikhovsky, Elena <elena.demikhovsky at intel.com>
> *Cc:* Hal Finkel <hfinkel at anl.gov>; Reid Kleckner <rnk at google.com>;
> cfe-dev <cfe-dev at lists.llvm.org>; Badouh, Asaf <asaf.badouh at intel.com>;
> Zuckerman, Michael <michael.zuckerman at intel.com>; David Majnemer <
> majnemer at google.com>; Chandler Carruth (chandlerc at google.com) <
> chandlerc at google.com>
>
>
> *Subject:* Re: [cfe-dev] The intrinsics headers (especially avx512) are
> too big. What to do about it?
>
>
>
> On Tue, May 17, 2016 at 3:49 PM, Demikhovsky, Elena <
> elena.demikhovsky at intel.com> wrote:
>
>    >Indeed. It is not clear to me, however, that this situation is
> desirable. We
>    >had a general policy that our intrinsics headers should generate
> generic IR
>    >whenever possible, and if we've strayed from that, we should discuss
> that
>    >first.
>
> Let's take a look at this intrinsic:
>
> static __inline__ __m512i __DEFAULT_FN_ATTRS
> _mm512_mask_add_epi64 (__m512i __W, __mmask8 __U, __m512i __A, __m512i __B)
> {
>   return (__m512i) __builtin_ia32_paddq512_mask ((__v8di) __A,
>              (__v8di) __B,
>              (__v8di) __W,
>              (__mmask8) __U);
> }
>
> The IR that should be generated:
> %C = add <8 x double> %B, %A
> %res = select <8 x i1> %mask, <8 x double> %C, %W
>
> If we parse __builtin_ia32_paddq512_mask in CGBuiltin.cpp and generate IR
> there, will it help?
>
> (Please do not consider my question as a general Intel solution. I just
> want to understand the problem.)
>
>
> The bit I care most about is that adding `#include <intrin.h>` shouldn't
> add megabytes of stuff to my translation unit.
>
>
>
> 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.
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> 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/20160620/7128d9e6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17591 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160620/7128d9e6/attachment.png>