https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-11-25
Ever confirmed|0 |1
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Probably skvx::cast<uint16_t> is the most intrusive one here ending up with
_37 = MEM[(const struct Vec &)&D.98687 + 15].val;
x_38 = (short unsigned int) _37;
_39 = MEM[(const struct Vec &)&D.98687 + 14].val;
x_40 = (short unsigned int) _39;
_41 = MEM[(const struct Vec &)&D.98687 + 13].val;
x_42 = (short unsigned int) _41;
...
c.hi.lo.hi.hi.val = x_46;
c.hi.hi.lo.lo.val = x_44;
c.hi.hi.lo.hi.val = x_42;
c.hi.hi.hi.lo.val = x_40;
c.hi.hi.hi.hi.val = x_38;
_73 = MEM <vector(16) short unsigned int> [(char * {ref-all})&c];
and expecting some kind of upack() to be used. It's template magic though.
But yes, we're missing "patterns" to detect VEC_* tree codes like
VEC_UPACK_{HI,LO}_EXPR from straight-line code and basic-block vectorization
isn't tuned for multiple sizes / "unpacking reductions" and thus does't
work here either, more specifically it first fails at the appearant mismatch
here:
_32 = (unsigned char) src_2;
_33 = BIT_FIELD_REF <src_2, 8, 8>;
(BIT_FIELD_REF vs. cast). But then it would fail at the common source
of the op:
src_2 = MEM[(struct Vec *)&D.151762];
because that's not a grouped store (and it has a vector type, something
BB vectorization doesn't like too much either).
It does vectorize some stmts, but it only goes up to blind vector
construction for the uniform vector cases (at least that).
