value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146]
authorRichard Sandiford <richard.sandiford@arm.com>
Sat, 11 Jul 2020 12:25:26 +0000 (13:25 +0100)
committerRichard Sandiford <richard.sandiford@arm.com>
Sat, 11 Jul 2020 12:25:26 +0000 (13:25 +0100)
commit505032d97d0593d5e9a6f51b107650e27fcf6b23
tree7c1f47b339701787e6a10082e7516f40a3ee562d
parentc19f95fb1b8f15090eb1d1682e86de425fbd3c78
value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146]

The range infrastructure has code to decompose POLY_INT_CST ranges
to worst-case integer bounds.  However, it had the fundamental flaw
(obvious in hindsight) that it applied to anti-ranges too, meaning
that a range 2+2X would end up with a range of ~[2, +INF], i.e.
[-INF, 1].  This patch decays to varying in that case instead.

I'm still a bit uneasy about this.  ISTM that in terms of
generality:

  SSA_NAME => POLY_INT_CST => INTEGER_CST
           => ADDR_EXPR

I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST
could store an INTEGER_CST (before canonicalisation).  POLY_INT_CST
is also “as constant as” ADDR_EXPR (well, OK, only some ADDR_EXPRs
are run-time rather than link-time constants, whereas all POLY_INT_CSTs
are, but still).  So it seems like we should at least be able to treat
POLY_INT_CST as symbolic.  On the other hand, I don't have any examples
in which that would be useful.

gcc/
PR tree-optimization/96146
* value-range.cc (value_range::set): Only decompose POLY_INT_CST
bounds to integers for VR_RANGE.  Decay to VR_VARYING for anti-ranges
involving POLY_INT_CSTs.

gcc/testsuite/
PR tree-optimization/96146
* gcc.target/aarch64/sve/acle/general/pr96146.c: New test.
gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96146.c [new file with mode: 0644]
gcc/value-range.cc