https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104759
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[12 Regression] |[11/12 Regression]
|gcc.dg/vect/vect-multitypes |gcc.dg/vect/vect-multitypes
|-12.c FAILs |-12.c FAILs
Keywords|missed-optimization |
Priority|P3 |P2
Target Milestone|12.0 |11.3
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, this was backported to GCC 11 as well.
With a cc1 cross to sparc-sun-solaris2.11 on the GCC 10 branch I see
the initialization loop vectorized as
.LL10:
st %g2, [%fp-280]
xor %g2, %g3, %o7
and %g2, %o5, %i0
st %g1, [%fp-276]
xor %g1, %g3, %i1
and %g1, %o5, %i4
ldd [%fp-280], %f8
and %o7, %o4, %o7
add %i0, %g3, %i0
and %i1, %o4, %i1
add %i4, %g3, %i4
std %f8, [%g4]
xor %o7, %i0, %i2
xor %i1, %i4, %i3
add %g4, 8, %g4
mov %i2, %g2
cmp %g4, %o3
bne,pt %icc, .LL10
where we indeed vectorize with V8QImode operations but have vector lowering
decompose them to
<bb 3> [local count: 132284996]:
# vect_vec_iv_.26_12 = PHI <{ 0, 1, 2, 3, 4, 5, 6, 7 }(2), _44(3)>
# ivtmp.42_38 = PHI <ivtmp.42_40(2), ivtmp.42_39(3)>
_29 = BIT_FIELD_REF <vect_vec_iv_.26_12, 32, 0>;
_22 = _29 ^ 134744072;
_27 = _29 & 2139062143;
_4 = _22 & 2155905152;
_5 = _27 + 134744072;
_9 = _4 ^ _5;
_10 = BIT_FIELD_REF <vect_vec_iv_.26_12, 32, 32>;
_18 = _10 ^ 134744072;
_26 = _10 & 2139062143;
_31 = _18 & 2155905152;
_32 = _26 + 134744072;
_35 = _31 ^ _32;
_36 = {_9, _35};
_44 = VIEW_CONVERT_EXPR<vector(8) char>(_36);
_41 = (void *) ivtmp.42_38;
MEM[base: _41, offset: 0B] = vect_vec_iv_.26_12;
ivtmp.42_39 = ivtmp.42_38 + 8;
if (ivtmp.42_39 != _43)
so I think this is an improvement code-generation wise, not a regression.
