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

[Andrew MacLeod]

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?


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