Re: On-Demand range technology [5/5] - Looking to the future.

[Richard Biener <richard.guenther@gmail.com>]

On Fri, May 24, 2019 at 5:51 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>
> On 5/23/19 10:07 AM, Richard Biener wrote:
> > On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod <amacleod@redhat.com> wrote:
> >>
> >> This aspect of all calculations being driven from the opcode and
> >> combined generically without special casing at  a higher level is both
> >> very powerful and less prone to produce errors. Our initial experiences
> >> involved debugging a lot of ranges because they didn’t look right… but
> >> it would inevitably turn out that a sequence of statements and
> >> conditions ended up determining an unexpected range, we just couldn’t
> >> understand from looking at it how it was arrived at.
> > Sounds like those primitive workers for ranges, relations and bitmasks
> > should be factored out where they are not already as a prerequesite,
> > not as some future project?  Note the bitmask ones are already
> > (just residing in tree-ssa-ccp.c), likewise the wide-int based range
> > ones are (mostly I think).  Relations are missing unfortunately
> > and passes like tree-ssa-uninit.c would benefit from such machinery
> > (or rather contain another copy of such machinery).
> >
> > Of course factoring always comes with commoning because usually
> > in GCC you find at least two implementations of everything.
> >
> > Richard.
> >
> >
> Yes, this would indeed be the case, I also consider the relations
> functionality as required, or to at least demonstrate a viable path
> forward that is being worked on. The bitmask operations are currently
> only used in full VRP (?) but they probably aren't a lot of work, I'd
> put them at a lower priority until VRP is slated to go.
>
> I would really like to see a single implementation for each of these
> things centrally maintained and handled generically.   At this point I
> don't think it was  realistic to proceed any further until we get some
> sort of agreement on a path forward to base it on.  we have found trying
> to maintain a common base with VRP just for ranges to be a fair amount
> of work on the side, so adding other things on top of that seems
> nightmarish :-)
>
>
> So let me see if I can summarize everything to this point.
>
> 1 * The range-ops infrastructure to solve for other operands coupled
> with the windback calculations within a block is desirable to replace
> the assert mechanism.
> 2 * common rangeops-like primitives for relational and bitmask  also
> seems desirable.
> 3 * You are not convinced the on demand component can/should replace the
> EVRP dominator walk.
>
> Does that about sum it up?

Yes.  For 1 EVRP already doesn't use asserts and I dislike VRP mostly
because of the asserts.  EVRP doesn't have symbolic ranges so it would
benefit from range-ops as well.

Yes, I'm not convinced that replacing a simple forward walk on the
dominators is to be replaced by using whatever on-demand infrastructure
we have on each and every stmt.  But in the end the difference should be
to just not using the GORI cache but the workers themselves which
should speed up things and remove the caching memory overhead.

The current ranges stuff got heavily penaltized by refactoring it into
C++, splitting over a dozen files and using virtual function calls, so
comparing speed is unfair within the current sturcture.

> 1 - The way everything is structured, both range-ops and the
> gori-computational component are independent of the on-demand engine.
> There is reason to believe those can be integrated with E/VRP as we are
> sort of doing that under the covers now.
>       what function does register_edge_assert() perform?  is it
> producing ranges just for outgoing edges for a block?
> and then you apply
> whatever range you currently have to that and this gives you a range
> going into the block on the other end of the edge?   If so, that
> functionality maps pretty close to what gori-computes provides.  It has
> a single API which returns whatever range restrictions an edge puts on
> an ssa-name.

It's split into two steps but basically doing what you say.  One part
is register_edge_assert_for which does common analysis for
building ASSERT_EXPRs for VRP and building temporary ranges for
EVRP.  Then EVRP has try_find_new_range which for one of the
"asserts" computes the new value-range [on a specific BB entry edge].

>
> there would have to be some tweaking to work with symbolics since we
> hate those and they aren't currently handled.
>
>
> 2 - implementing range-ops like routines for relations and eventually
> bitmasks should not be too difficult. The process is pretty
> straightforward.

As said it already exists for bitmasks, see tree-ssa-ccp.c:bit_value_*

>  I will need to work on the relation tracking/querying,
> but that was pretty much in plan as the next task anyway.   I had pushed
> bitmasks way down the list as "eventually" since I think that is only in
> full VRP and a lower priority until considering VRP for removal.

Note that VRP doesn't really track bitmasks IIRC, it merely uses
those recorded on SSA names to prune ranges.

Richard.

>
> 3 - Give me a few days to mull over some details on how some of this may
> all coexist and I'll get back to you next week.
>
> Andrew