Re: On-Demand range technology [3/5] - The Prototype

[Andrew MacLeod <amacleod@redhat.com>]

On 5/23/19 9:10 AM, Richard Biener wrote:
> On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod <amacleod@redhat.com> wrote:
>>
>> This aspect of symbolics would be handled by a relational/equivalence
>> processing engine that would be follow on work.  Using the same basic
>> model as ranges, each tree code is taught to understand the relation
>> between its operands, and then we can answer equivalency and relational
>> accurately as well.  It would be available for any pass to use
>> independent of ranges. I will expound upon that a bit in the future
>> directions section.
> While I agree that symbolic ranges are a complication and that most
> cases it currently handles are not "value-range" things I do not agree
> with the idea that we can simply remove handling them and deal
> with the fallout in some later point in the future.  Eric may also be
> able to show you "real" symbolic value-range magic.

sure, I'd love to see a case we can't get that having symbolics in the 
range helps with.  (note I see you guys have replied with an example.  
I'll reply there, but will note it is actually a relation issue, so my 
assertion stands)

And we aren't talking about utting this code in and someday getting 
around to it.   Equivalencies/relations are the very next thing to 
tackle,  and I expected at least a proof of concept as a requirement.  I 
just don't want to proceed with any follow up work until a direction is 
set for the core aspects.

> Note that symbolic ranges are already restricted to PLUS_EXPR
> and MINUS_EXPR (and NEGATE_EXPR I think).  There are
> also "symbolic" (non-integer constant) ranges like [&a, &a].
> I've never seen [&a, &MEM[&a + 4]] but we wouldn't reject those
> I think.
>
> You may have noticed that EVRP does not use symbolic ranges.

Other than for equivalences?  it appears to still track them via ranges 
to eliminate things like :

if (a == b && b == c)
      if (a == c)

    Intersecting
       int [c_7(D), c_7(D)]  EQUIVALENCES: { b_6(D) c_7(D) } (2 elements)
    and
       VARYING
    to
       int [c_7(D), c_7(D)]  EQUIVALENCES: { b_6(D) c_7(D) } (2 elements)

I noticed this is how it continues to handle relational problems, so 
they are there.

>
> As already said I'd like to see VRP go but obstackles are
> symbolic ranges and jump-threading (with Jeff promising
> to handle the jump-threading part in the past).
>
I also consider symbolics an obstacle, only in a different way :-)

Andrew