https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-06-24
Keywords| |missed-optimization
Ever confirmed|0 |1
Target| |x86_64-pc-linux-gnu
Host|x86_64-pc-linux-gnu |
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
the issue is that likely (is that prerequesite patch in yet?)
vect_recog_over_widening_pattern is not detecting that the shift could be
done in smaller than int precision. C promotion rules gives us
_4 = *_3;
_5 = (int) _4;
_7 = *_6;
_8 = (int) _7;
_9 = _5 << _8;
_10 = (short unsigned int) _9;
*_3 = _10;
where promotion of the shift amount is a GCC choice. The first reason is
that we hit
/* See whether we have found that this operation can be done on a
narrower type without changing its semantics. */
unsigned int new_precision = last_stmt_info->operation_precision;
if (!new_precision)
return NULL;
which is because the analysis code seems to bail for non-constant shift
amounts with the fear to introduce shifts that are undefined (out-of-bounds).
But then the check above doesn't really factor in a possible truncation.
