search for: x86intrin

...rated. rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory configure: WARNING: using cross tools not prefixed with host triplet rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory configure: WARNING: x86intrin.h: present but cannot be compiled configure: WARNING: x86intrin.h: check for missing prerequisite headers? configure: WARNING: x86intrin.h: see the Autoconf documentation configure: WARNING: x86intrin.h: section "Present But Cannot Be Compiled" configure: WARNING: x86intrin.h: pro...

Erik de Castro Lopo wrote: > When should FLAC__HAS_X86INTRIN be defined? What header file should I be > checking for? Ah, should be checking for <x86intrin.h>. The rest seems to be coming together. Testing this now. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, even if x86intrin.h is not available. 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': AM_CONDITIONAL(FLaC__SSE_OS, test "x$sse_os" = xtrue) It seems that it should be changed to AM_CONDITIONAL(...

...doesn't actually work. I'll fix that. > 2. xapian-core when built with GCC: > > checking whether __builtin_add_overflow is declared... yes > ... > checking whether _addcarry_u64 is declared... no > > There is actually _addcarry_u64 in GCC too, but it's in x86intrin.h > instead of intrin.h. This is no problem either, since it's superimposed > by __builtin_add_overflow anyway. I think __builtin_add_overflow() is going to be as good an option (and possibly a better option where both are supported) so this doesn't seem a problem unless there's...

...isgerber naddy at mips.inka.de -------------- next part -------------- Index: configure.ac --- configure.ac.orig +++ configure.ac @@ -69,7 +69,7 @@ AC_C_INLINE AC_C_VARARRAYS AC_C_TYPEOF -AC_CHECK_HEADERS([stdint.h inttypes.h byteswap.h sys/param.h sys/ioctl.h termios.h x86intrin.h cpuid.h]) +AC_CHECK_HEADERS([stdint.h inttypes.h byteswap.h sys/param.h sys/ioctl.h termios.h x86intrin.h cpuid.h sys/auxv.h]) XIPH_C_BSWAP32 XIPH_C_BSWAP16 @@ -104,6 +104,8 @@ AC_CHECK_TYPES(socklen_t, [], []) dnl check for getopt in standard library dnl AC_CHECK_FUNCS(getopt_long , , [LIB...

lvqcl wrote: > lvqcl wrote: > > > 1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, > > even if x86intrin.h is not available. > > > > 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': > > The patch is attached. Please check it. Looks good. I need to do a little testing...

...r rdoc... /usr/bin/rdoc Looks curious but no problem since it's found anyway. 2. xapian-core when built with GCC: checking whether __builtin_add_overflow is declared... yes ... checking whether _addcarry_u64 is declared... no There is actually _addcarry_u64 in GCC too, but it's in x86intrin.h instead of intrin.h. This is no problem either, since it's superimposed by __builtin_add_overflow anyway. Thanks,

Sorry in advance for the limited details. I have a build of a recent (Monday) llvm/clang which I have installed in the expected way in my environment but I am getting failures like this; In file included from <some directory>/lib/clang/stable/include/x86intrin.h:29: In file included from <some directory>/lib/clang/stable/include/immintrin.h:118: <some directory>/lib/clang/stable/include/avx512cdintrin.h:37:20: error: use of undeclared identifier '__builtin_ia32_vpconflictdi_512' return (__m512i) __builtin_ia32_vpconflictdi_512 ((__v...

...ted details. > > > > I have a build of a recent (Monday) llvm/clang which I have installed in the expected way in my environment but I am getting failures like this; > > > > In file included from <some directory>/lib/clang/stable/include/x86intrin.h:29: > > In file included from <some directory>/lib/clang/stable/include/immintrin.h:118: > > <some directory>/lib/clang/stable/include/avx512cdintrin.h:37:20: error: use of undeclared identifier '__builtin_ia32_vpconflictdi_512' > >...

...propose adding the -mprefer-avx256 and -mprefer-avx128 command line flags supported by latest GCC to clang. These flags will be used to limit the vector register size presented by TTI to the vectorizers. The backend will still be able to use wider registers for code written using the instrinsics in x86intrin.h. And the backend will still be able to use AVX512VL instructions and the additional XMM16-31 and YMM16-31 registers. Motivation: -Using 512-bit operations on some Intel CPUs may cause a decrease in CPU frequency that may offset the gains from using the wider register size. See section 15.26 o...

...included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0:909: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: 1> In file included from C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: 1>C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): error : cannot initialize a parameter of type '__attribute__((__vector_size__(2 *...

Hi, I love llvm vectors, yet I wonder why some advanced vector operations are specific to some CPU targets? Let me take an example: /// Horizontally adds the adjacent pairs of values contained in two /// 128-bit vectors of [4 x float]. /// /// \headerfile <x86intrin.h> /// /// This intrinsic corresponds to the <c> VHADDPS </c> instruction. /// /// \param __a /// A 128-bit vector of [4 x float] containing one of the source operands. /// The horizontal sums of the values are stored in the lower bits of the /// destination. /// \param __b...

...hoisted it into a single lfence intrinsic before the branch. https://godbolt.org/z/qMc446 The intrinsic in IR has no properties so it should be assumed to read/write any memory. But that's not enough to specify this control flow dependency. gcc also exhibits a similar behavior. #include <x86intrin.h> void bar(); void baz(); void foo(int c) { if (c) { _mm_lfence(); bar(); } else { _mm_lfence(); baz(); } } Alternatively, I also tried replacing the intrinsics with inline assembly. SimplifyCFG still merged those. But gcc did not. https://godbolt.org/z/acnPxY...

...osoft Visual > Studio 12.0\VC\include\xmemory0:909: > 1> In file included from C:\Program Files > (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: > 1> In file included from C:\Program Files > (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: > 1> In file included from C:\Program Files > (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: > 1>C:\Program Files > (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): > error : cannot initialize a parameter of type...

...nd -mprefer-avx128 >> command line flags supported by latest GCC to clang. These flags will be >> used to limit the vector register size presented by TTI to the vectorizers. >> The backend will still be able to use wider registers for code written >> using the instrinsics in x86intrin.h. And the backend will still be able to >> use AVX512VL instructions and the additional XMM16-31 and YMM16-31 >> registers. >> >> >> >> Motivation: >> >> -Using 512-bit operations on some Intel CPUs may cause a decrease in CPU >> frequency that...

Hi Michael, >Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. Yes, correct, this a little bit changed example is not working. #include <x86intrin.h> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { __m256d foo = (__m256d){ ptr[i], ptr[i+1], ptr[i+2], ptr[i+3] }; return __builtin_shufflevector( foo, foo, 3, 3, 2, 2 ); } But with the aggregate case it is a new level of complexity, should we we care about? There might be...

...er why some advanced vector operations are >> specific to some CPU targets? >> >> Let me take an example: >> >> /// Horizontally adds the adjacent pairs of values contained in two >> /// 128-bit vectors of [4 x float]. >> /// >> /// \headerfile <x86intrin.h> >> /// >> /// This intrinsic corresponds to the <c> VHADDPS </c> instruction. >> /// >> /// \param __a >> /// A 128-bit vector of [4 x float] containing one of the source >> operands. >> /// The horizontal sums of the values are stor...

...osoft Visual Studio >> 12.0\VC\include\xmemory0:909: >> 1> In file included from C:\Program Files >> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: >> 1> In file included from C:\Program Files >> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: >> 1> In file included from C:\Program Files >> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: >> 1>C:\Program Files >> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): error >> : cannot initialize a parameter of type...

Hey LLVMDev, Perhaps I'm missing something, but I think I've stumbled across a codegen bug in LLVM 10.0.1 related to AVX512. I've attached a small LLVM IR testcase and generated x86_64 assembly file that shows the bug. The test case is small, but not quite minimal, mostly because of driver code included in the test case so one can compile and run the program. The program does a

...> Hi Michael, >>> Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. >> Yes, correct, this a little bit changed example is not working. >> #include <x86intrin.h> >> >> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { >> __m256d foo = (__m256d){ ptr[i], ptr[i+1], ptr[i+2], ptr[i+3] }; >> return __builtin_shufflevector( foo, foo, 3, 3, 2, 2 ); >> } >> But with the aggregate case it is a new level...