On Thu, Mar 21, 2024 at 06:09:01PM +0100, Thomas Monjalon wrote: > 20/03/2024 22:12, Tyler Retzlaff: > > +#ifdef RTE_TOOLCHAIN_MSVC > > +#include <intrin.h> > > +#else > > #include <x86intrin.h> > > +#endif > > It is not the same include in MSVC?
unfortunately intrin.h is vestigial in the monolithic approach. to use any intrinsic you're supposed to include only the one and only true header instead of vendor/arch feature specific headers. > Is it something we want to wrap in a DPDK header file? do you mean create a monolithic rte_intrinsic.h header that is essentially #ifdef MSVC #include <intrin.h> #else #include <x86intrin.h> #include <immintrin.h> #include <nmmintrin.h> ... #endif i assumed that doing something like this might be unpopular due to the unnecessary namespace pollution. another alternative could be to find a way to limit that pollution only to msvc by stashing intrin.h in e.g. rte_common.h (or rte_os.h) under conditional compile but the problem i think we had with that approach is that some llvm headers don't define prototypes that match those from msvc see lib/eal/windows/include/rte_windows.h another issue arises where if the application includes intrin.h before dpdk headers we again have to deal with llvm vs msvc differences. fwiw the instance highlighted llvm should have volatile qualified in their prototype but didn't. i will commit to looking into this more after applications are working.