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).