Re: Add a constant_range_value_p function (PR 92033)

[Aldy Hernandez <aldyh at redhat dot com>]

On 10/14/19 12:38 PM, Richard Biener wrote:
> On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford <richard.sandiford@arm.com> wrote:
> > Richard Biener <richard.guenther@gmail.com> writes:
> > > On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
> > > <richard.sandiford@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