[Bug target/97457] [10/11 Regression] SVE: wrong code since r10-4752-g2d56600c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97457

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:54ef7701a9dec8c923a12d1983f8a051ba88a7b9

commit r11-4495-g54ef7701a9dec8c923a12d1983f8a051ba88a7b9
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Oct 28 19:05:49 2020 +0000

    value-range: Give up on POLY_INT_CST ranges [PR97457]

    This PR shows another problem with calculating value ranges for
    POLY_INT_CSTs.  We have:

      ivtmp_76 = ASSERT_EXPR <ivtmp_60, ivtmp_60 > POLY_INT_CST [9,
4294967294]>

    where the VQ coefficient is unsigned but is effectively acting
    as a negative number.  We wrongly give the POLY_INT_CST the range:

      [9, INT_MAX]

    and things go downhill from there: later iterations of the unrolled
    epilogue are wrongly removed as dead.

    I guess this is the final nail in the coffin for doing VRP on
    POLY_INT_CSTs.  For other similarly exotic testcases we could have
    overflow for any coefficient, not just those that could be treated
    as contextually negative.

    Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
    couldn't handle warn_strict_overflow properly.  At this stage we're
    just recording a range that might or might not lead to strict-overflow
    assumptions later.

    It still feels like we should be able to do something here, but for
    now removing the code seems safest.  It's also telling that there
    are no testsuite failures on SVE from doing this.

    gcc/
            PR tree-optimization/97457
            * value-range.cc (irange::set): Don't decay POLY_INT_CST ranges
            to integer ranges.

    gcc/testsuite/
            PR tree-optimization/97457
            * gcc.dg/vect/pr97457.c: New test.