On 12/2/20 9:27 AM, Richard Sandiford via Gcc-patches wrote:
> This is a gcc-10 version of:
>
> Richard Sandiford <richard.sandif...@arm.com> writes:
>> 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.
>>
>> Tested on aarch64-linux-gnu (with and without SVE) and
>> x86_64-linux-gnu. OK for trunk and backports?
>>
>> Richard
> The backport ended up looking a bit different. Rather than fall through
> to the later VR_VARYING code (which asserts for certain min and max values),
> this code just moves directly to varying.
Yea, lots has changed in this area over the last year.
>
> Tested on aarch64-linux-gnu, aarch64_be-elf, arm-linux-gnueabihf,
> armeb-elf and x86_64-linux-gnu. OK for GCC 10?
>
> Richard
>
>
> 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.
Backport is fine.
jeff
