On 10/14/19 12:38 PM, Richard Biener wrote:
On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford
<richard.sandif...@arm.com> wrote:
Richard Biener <richard.guent...@gmail.com> writes:
On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
<richard.sandif...@arm.com> wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
ADDR_EXPR". It seems better to add a predicate specifically for
that rather than contiually fight cases in which it can't handle
other invariants.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
ICK. Nobody is going to remember this new restriction and
constant_range_value_p reads like constant_value_range_p ;)
Btw, is_gimple_invariant_address shouldn't have been exported,
it's only use could have used is_gimple_min_invariant...
What do you think we should do instead?
Just handle POLY_INT_CST in a few place to quickly enough drop to varying.
I don't care either way, but I had originally suggested:
I was going to suggest we normalize ranges to numerics completely before
folding. That is, replacing normalize_addresses() here:
*vr = op->fold_range (expr_type,
vr0.normalize_addresses (),
vr1.normalize_addresses ());
...into normalize_symbolics().
This will allow ranges of POLY_INTs to live throughout, but will get
dropped right before any arithmetic on them. At the least, it's a two
line change (assuming there are no hidden gotchas ;-)).
Aldy