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

Nathan Froyd via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 29 10:50:37 PDT 2016


[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?

Thanks,
-Nathan



More information about the cfe-dev mailing list