search for: _mm_loadl_epi64

Hi, I’m using _mm_storel_epi64/ _mm_loadl_epi64 in my test case as below and generating 32-bit code (using -m32 and -msse4.2). The 64-bit load and 64-bit store operations are replaced with two 32-bit mov instructions, presumably due to the use of uint64_t type. If I use __m128i instead of uint64_t everywhere, then the read and write happen as 64...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_xv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c index 8eafcf0..567e30c 100644 --- a/src/nouveau_xv.c +++ b/src/nouveau_xv.c @@ -552,8 +552,11 @@ NVCopyNV12ColorPlanes(unsigned char *src1, unsigned char *src2, if (e) { unsigned short *vud = (unsigned

...< h; j++) { unsigned char *us = src1; unsigned char *vs = src2; unsigned int *vuvud = (unsigned int *) dst; + unsigned short *vud; for (i = 0; i < l; i++) { -#if X_BYTE_ORDER == X_BIG_ENDIAN +#ifdef __SSE2__ + _mm_storeu_si128( + (void*)vuvud, + _mm_unpacklo_epi8( + _mm_loadl_epi64((void*)vs), + _mm_loadl_epi64((void*)us))); + vuvud+=4; + us+=8; + vs+=8; +#else /* __SSE2__ */ +# if X_BYTE_ORDER == X_BIG_ENDIAN *vuvud++ = (vs[0]<<24) | (us[0]<<16) | (vs[1]<<8) | us[1]; -#else +# else *vuvud++ = vs[0] | (us[0]<<8) | (vs[1]<<16)...

Hi, Please find attached a patch to fix alignment exceptions. Without this change, we were seeing occasional alignment faults when using this with clang. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170818/e0d6bb06/attachment.html> -------------- next part -------------- A non-text

...> This would revert a patch I submitted two years ago ( > http://git.xiph.org/?p=opus.git;a=commitdiff;h=1d60b49e9d95672a17ebe5578319c59fa3963224 > ). > > At the time, clang produced an unnecessary MOVQ instruction when it > compiled with the version of the code with the explicit _mm_loadl_epi64 > intrinsic. Do you no longer see that? > > How does the code compile for you, and what is the issue you’re seeing? > (One issue might be that clang’s address sanitizer isn’t smart enough to > know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s > argument being a...

...ert a patch I submitted two years ago ( >> http://git.xiph.org/?p=opus.git;a=commitdiff;h= >> 1d60b49e9d95672a17ebe5578319c59fa3963224). >> >> At the time, clang produced an unnecessary MOVQ instruction when it >> compiled with the version of the code with the explicit _mm_loadl_epi64 >> intrinsic. Do you no longer see that? >> >> How does the code compile for you, and what is the issue you’re seeing? >> (One issue might be that clang’s address sanitizer isn’t smart enough to >> know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s &...

This would revert a patch I submitted two years ago (http://git.xiph.org/?p=opus.git;a=commitdiff;h=1d60b49e9d95672a17ebe5578319c59fa3963224). At the time, clang produced an unnecessary MOVQ instruction when it compiled with the version of the code with the explicit _mm_loadl_epi64 intrinsic. Do you no longer see that? How does the code compile for you, and what is the issue you’re seeing? (One issue might be that clang’s address sanitizer isn’t smart enough to know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s argument being an __mm128i; I’ve seen it trig...

...han at vidyo.com>> wrote: This would revert a patch I submitted two years ago (http://git.xiph.org/?p=opus.git;a=commitdiff;h=1d60b49e9d95672a17ebe5578319c59fa3963224). At the time, clang produced an unnecessary MOVQ instruction when it compiled with the version of the code with the explicit _mm_loadl_epi64 intrinsic. Do you no longer see that? How does the code compile for you, and what is the issue you’re seeing? (One issue might be that clang’s address sanitizer isn’t smart enough to know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s argument being an __mm128i; I’ve seen it trig...

...t thing, though does *not* optimize out + the extra MOVQ if it's specified explicitly */ + # if defined(__clang__) || !defined(__OPTIMIZE__) # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(_mm_cvtsi32_si128(*(int *)(x)))) - -# define OP_CVTEPI16_EPI32_M64(x) \ - (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) # else # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(*(__m128i *)(x))) +#endif +# if !defined(__OPTIMIZE__) +# define OP_CVTEPI16_EPI32_M64(x) \ + (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) +# else # define OP_CVTEPI16_EPI32_M64(x) \ (_mm_cvtepi16_ep...

...t thing, though does *not* optimize out + the extra MOVQ if it's specified explicitly */ + # if defined(__clang__) || !defined(__OPTIMIZE__) # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(_mm_cvtsi32_si128(*(int *)(x)))) - -# define OP_CVTEPI16_EPI32_M64(x) \ - (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) # else # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(*(__m128i *)(x))) +#endif +# if !defined(__OPTIMIZE__) +# define OP_CVTEPI16_EPI32_M64(x) \ + (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) +# else # define OP_CVTEPI16_EPI32_M64(x) \ (_mm_cvtepi16_ep...

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work