https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-08-28
Summary|__m128i from _mm_set_epi32 |[10/11 Regression] __m128i
|is backwards with -O3 |from _mm_set_epi32 is
| |backwards with -O3
Ever confirmed|0 |1
CC| |avieira at gcc dot gnu.org,
| |joel.hutton at arm dot com
Target Milestone|--- |10.3
Priority|P3 |P2
Status|UNCONFIRMED |NEW
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I can reproduce that one, started with
r10-4336-g818b3293f4545d899148810f4f7d676b81e989dd
The first difference between the commit right before that one and r10-4336 is
in slp1 pass:
_5 = dude_[3];
_6 = (int) _5;
_7 = dude_[2];
_8 = (int) _7;
_9 = dude_[1];
_10 = (int) _9;
+ vect__11.11_30 = MEM <vector(4) unsigned int> [(unsigned int *)&dude_];
_11 = dude_[0];
+ vect__12.12_40 = VIEW_CONVERT_EXPR<vector(4) int>(vect__11.11_30);
_12 = (int) _11;
- _22 = {_6, _8, _10, _12};
+ _22 = vect__12.12_40;
_28 = VIEW_CONVERT_EXPR<__m128i>(_22);
*dude_23(D) = _28;
dude_ ={v} {CLOBBER};
and that changes the element ordering in the _22 vector, previously it was
dude_[3], dude_[2], dude_[1], dude_[0], newly it is read from the memory which
is the exact opposite order. The _22 = {_6, _8, _10, _12} is what is in the IL
before slp1, so clearly this is a SLP introduced breakage.
