https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113025
juki at gcc dot mail.kapsi.fi changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |FIXED
--- Comment #2 from juki at gcc dot mail.kapsi.fi ---
Unfortunately alignment of the cast type was not causing this issue.
I changed all calls that were defined in GCC headers to use __m128i_u or
__m128d_u types to use those types before unaligned intrinsic.
For example LOAD_SI128 macro looks like the following:
#define LOAD_SI128(ptr) \
( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
_mm_loadu_si128((__m128i_u*)(ptr))
My changes only changed the debug information locations but did not lead to the
generation of different kind of load operations. In fact, generated assembly
was identical outside of debug line information changes:
$ diff -u0 orig.s fixed.s|grep movdq| wc
0 0 0
But if aligned loads are removed completely as an option and only unaligned
loads (even with the wrong intrinsic type) are used, no invalid aligned loads
are generated and assembly changes significantly regarding movdq* instructions:
#define LOAD_SI128(ptr) \
( 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
_mm_loadu_si128((__m128i*)(ptr))
diff -u0 orig.s align-loads-removed.s|grep movdq| wc
11001 44004 263376
Above code fixes all our invalid instruction generation while only using
correct types does not.
While I can't share the related sources, I could still try to run different
tests locally to see what is be causing the issue. What could I do next to help
solve this as I do have reliable test cases to work with.
