https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66278
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to be overly conservative tree-chrec.c code.
chrec_fold_plus is called on
(sizetype) {i_5, +, 1}_1 and 30906
where loop->nb_iterations_upper_bound is 100 and
loop->nb_iterations is (unsigned int) _4 + 1 <= 101 ? 100 - (unsigned int) _4 :
0
It is a pitty we don't use range info on _4 when simplifying
loop->nb_iterations, here it is [0, 1], so we could at least easily find out
that (unsigned int) _4 + 1 <= 101 is always true.
Anyway, chrec_fold_plus just gives up on:
CASE_CONVERT:
if (tree_contains_chrecs (op0, NULL))
return chrec_dont_know;
eventhough from the loop bounds in this case it could prove that for all loop
iterations the chrec always fits into the narrower type, including the addition
and thus it can safely move the addition into the chrec's op0.
If I change [3][3] to [0][0], then the problem is in chrec_fold_multiply
instead (again, we have (sizetype) i_16 * 4 and give up because of the cast).
If the testcase is modified, so that it uses unsigned long as i and next type,
then it is vectorized fine.
