On 5/23/19 10:07 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod <amacl...@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?
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.
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. 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.
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
