[cfe-dev] clang-cl's <intrin.h>, _tzcnt_u32, and compatibility with MSVC's <intrin.h>
Hans Wennborg via cfe-dev
cfe-dev at lists.llvm.org
Thu Sep 29 11:04:09 PDT 2016
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.
More information about the cfe-dev
mailing list