While performing surgery on #935 to make it header-only for /clr:pure compatibility, I made <complex> drag in arm64_neon.h:
|
#elif defined(_M_IX86) || defined(_M_X64)
|
|
#define _FMP_USING_X86_X64_INTRINSICS
|
|
#include <emmintrin.h>
|
|
#include <isa_availability.h>
|
|
extern "C" int __isa_available;
|
|
extern "C" __m128d __cdecl _mm_fmsub_sd(__m128d, __m128d, __m128d);
|
|
#elif defined(_M_ARM64)
|
|
#define _FMP_USING_ARM64_INTRINSICS
|
|
#include <arm64_neon.h>
|
|
#endif // ^^^ defined(_M_ARM64) ^^^
|
@statementreply observed that arm64_neon.h declares a zillion non-_Ugly identifiers and macros.
We should consider doing something about this. Possibilities:
- @CaseyCarter suggested extracting a small subheader (possibly into
intrin0.h itself) with just what the STL needs. This would also be good for x86/x64 emmintrin.h.
- Wait for vNext and after
/clr:pure is erased from human memory, go back to @statementreply's original separately compiled design, which avoids this identifier pollution.
- Hybrid approach: Continue to use the header-only, non-intrinsic code for
/clr:pure, but separately compile the intrinsics for use by native and /clr code. (The only reason I didn't try this was time pressure.)
While performing surgery on #935 to make it header-only for
/clr:purecompatibility, I made<complex>drag inarm64_neon.h:STL/stl/inc/complex
Lines 23 to 32 in 19c683d
@statementreply observed that
arm64_neon.hdeclares a zillion non-_Uglyidentifiers and macros.We should consider doing something about this. Possibilities:
intrin0.hitself) with just what the STL needs. This would also be good for x86/x64emmintrin.h./clr:pureis erased from human memory, go back to @statementreply's original separately compiled design, which avoids this identifier pollution./clr:pure, but separately compile the intrinsics for use by native and/clrcode. (The only reason I didn't try this was time pressure.)