[cfe-dev] clang-cl's <intrin.h>, _tzcnt_u32, and compatibility with MSVC's <intrin.h>

[Reid Kleckner via cfe-dev]

We've been here before:
https://llvm.org/bugs/show_bug.cgi?id=25544
http://llvm.org/viewvc/llvm-project?view=revision&revision=253358
https://bugs.chromium.org/p/chromium/issues/detail?id=556735

Nico's change to avoid including bmiintrin.h if _MSC_VER is set to reduce
compile time brought the problem back.

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.

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?

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.

On Thu, Sep 29, 2016 at 11:04 AM, Hans Wennborg <hans at chromium.org> wrote:

> On Thu, Sep 29, 2016 at 10:50 AM, Nathan Froyd via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > [While I filed this as https://llvm.org/bugs/show_bug.cgi?id=30506,
> > Paul Robinson suggested in the bug that it might be worth bringing to
> > cfe-dev for wider discussion.]
> >
> > Firefox's copy of FFmpeg includes <intrin.h> on MSVC:
> >
> > https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/
> libavutil/x86/intmath.h#26
> >
> > and MSVC's <intrin.h> (after including several other headers) declares
> > _tzcnt_u32.  clang-cl declares _tzcnt_u32 in <bmiintrin.h>, but
> > <bmiintrin.h> is only included from <intrin.h> if an appropriate
> > target CPU is detected:
> >
> > https://github.com/llvm-mirror/clang/blob/master/lib/Headers
> /immintrin.h#L82
> >
> > even though _tzcnt_u32 (or rather, its underlying implementation
> > function, __tzcnt_u32) is explicitly declared to be available
> > everywhere:
> >
> > https://github.com/llvm-mirror/clang/blob/master/lib/Headers
> /bmiintrin.h#L284
> >
> > The net result is that Firefox's copy of FFmpeg doesn't compile with
> > clang-cl because of this issue.  Upstream has the same code, so I
> > assume the same is true there:
> >
> > https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/intmath.h#L26
> >
> > AFAICT, this behavior was changed by only including <bmiitrin.h> if
> > __BMI__ is defined in:
> >
> > http://reviews.llvm.org/D20291
> >
> > with the desirable goal of reducing compile time.  But this change
> > also broke things like _tzcnt_u32 being available.
> >
> > What is the right thing to do here?  Should <bmiintrin.h> be
> > unconditionally included, or should something else be done?
>
> I think these intrinsics (it's really just tzcnt though?) that are
> useful also for non-BMI targets should probably be moved out of the
> BMI-specific  header.
>
> +thakis and rnk if they have any thoughts on this.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160929/2931c7da/attachment.html>