Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing implementation of xsimd::kernel::detail::interleave for AVX2 #1070

Closed
ni-eddiemond opened this issue Dec 10, 2024 · 4 comments · Fixed by #1083
Closed

Missing implementation of xsimd::kernel::detail::interleave for AVX2 #1070

ni-eddiemond opened this issue Dec 10, 2024 · 4 comments · Fixed by #1083

Comments

@ni-eddiemond
Copy link

The function xsimd::kernel::detail::interleave does not seem to be implemented for AVX2. It is however present in the SSE4.1 header. It would be great if the AVX2 header would not depend on the SSE4.1 header to be included beforehand but to be self-sufficient instead.
I get a compilation error because of this. I'm using with MSVC 17.12.2

constexpr int imask = detail::interleave(mask);

@serge-sans-paille
Copy link
Contributor

Can you provide a reproducer ? xsimd is available on godbolt ;-)

@ni-eddiemond
Copy link
Author

Unfortunately not because godbolt says 'Please note that Windows-based compilers currently do not support libraries. '

But as you can see in the xsimd_avx2 header, there is no interleave function defined in its detail namespace and there is no #include statement that would pull in a definition from somewhere else. So it's a conceptual issue.

@serge-sans-paille
Copy link
Contributor

ack. avx2 implementation depends on avx for some parts, which itself depends on sse4 for some parts (basically for fallbacks). The dependency is implicit (and not enforced, but it basically should) through https://github.com/xtensor-stack/xsimd/blob/0252ae756f660c00ffaba4af67bd7d32e1b0a72c/include/xsimd/arch/xsimd_isa.hpp

Should we just error when this is not respected?

@ni-eddiemond
Copy link
Author

Creating an explicit error (maybe a static_assert) is probably the best and easiest solution that can give users a hint at what's going wrong. It would have saved us some time knowing about that implicit dependency.

serge-sans-paille added a commit that referenced this issue Jan 26, 2025
… sse2)

Also add CI to make sure the assumption we make are correct on all
architectures supported by GCC.

Fix #1070
serge-sans-paille added a commit that referenced this issue Jan 26, 2025
… sse2)

Also add CI to make sure the assumption we make are correct on all
architectures supported by GCC.

Fix #1070
serge-sans-paille added a commit that referenced this issue Jan 26, 2025
… sse2)

Also add CI to make sure the assumption we make are correct on all
architectures supported by GCC.

Fix #1070
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants