https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126376
ptomsich at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ptomsich at gcc dot gnu.org
--- Comment #5 from ptomsich at gcc dot gnu.org ---
To build on Kostas's reply: we did prototype the SLP side, and this is what
pushed us to the cunrolli change. This should be considered less of a stopgap
than "workaround" might suggest.
The key point is that recognizing DOT_PROD in the unrolled, straight-line body
doesn't actually recover the dot-product. A single DOT_PROD_EXPR is one
multiply-accumulate and (in loop vectorization) the VF supplies the batching
(VF=16 => one udot/usdot). In BB-SLP there is no VF, so we end up with just a
widening multiply. To get the dot product, we'd need to re-roll the 16-element
chain that cunrolli just flattened.
If we keep the reduction loop, we get the optimal inner loop and
vect_recog_dot_prod_pattern still has the reduction PHI. Completely unrolling a
small constant-trip reduction that one of the next relevant passes would turn
into a single DOT_PROD is a cunrolli cost-model issue. Not unrolling in that
specific case is a targeted fix.
Our experiments have shown that after unrolling, there's no reduction PHI left
and STMT_VINFO_REDUC_IDX == -1, so the existing reduction-based recognizers
don't apply. Then, over_widening rewrites the multiplies to 16-bit before the
SLP tree, so a straight-line recognizer doesn't even see the i8×u8->i32.
