[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #4)
> As the summary mentions 'volatile' I'll also point to the implementation of
> the intrinsics which have
> 
> /* Store four SPFP values.  The address must be 16-byte aligned.  */
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_store_ps (float *__P, __m128 __A)
> {
>   *(__v4sf *)__P = (__v4sf)__A;
> }
> 
> so they are not using a volatile qualified type to access *__P which means
> the stores are not considered volatile by GCC.
> 
> The arguments about strict-aliasing requirements still hold, only __m128 is
> declared as __may_alias__:
> 
> /* The Intel API is flexible enough that we must allow aliasing with other
>    vector types, and their scalar components.  */
> typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
> 
> /* Internal data types for implementing the intrinsics.  */
> typedef float __v4sf __attribute__ ((__vector_size__ (16)));
> 
> so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
> the by value passed __A has no effect).
> 
> -> target "bug", but I'd say an INVALID one.
> 
> HJ, I remember the "master" copy of the intrinsics documentation is
> somewhere at Intel - what does that say to the two above issues?
> 
> Thus all of this boils down to the question whether the intrinsics are
> implemented correctly (as documented).  The volatile part of it would
> mean to either pessimize all users or that we can't implement the
> intrinsics as C functions.

_mm_store_ps is documented in Intel SDM for movaps.  It doesn't say
anything about aliasing.