[RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR

[Jeff Law]

On 02/07/2017 01:39 AM, Richard Biener wrote:
> On Mon, Feb 6, 2017 at 10:57 PM, Jeff Law <law@redhat.com> wrote:
>> On 02/06/2017 08:33 AM, Richard Biener wrote:
>>
>>> ah, indeed vr0type is VR_ANTI_RANGE and yes we have the case of a
>>> range with an anti-range "inside".  This also covers [-1,1] v
>>> ~[0,0] where you choose the much larger anti-range now.  So at
>>> least we want to have some idea about the sizes of the ranges
>>> (ideally we'd choose the smaller though for most further
>>> propagations anti-ranges often degenerate to varying...)
>>
>> vr0 as an anti-singleton range like ~[0,0] is the only one likely
>> of any interest right now and that's always going to have a range
>> that is all but one value :-)
>>
>> vr1 is the tricky case.  We could do v1.max - vr1.min and if that
>> overflows or is some "large" value (say > 65536 just to throw out a
>> value), then we conclude creating the singleton anti-range like
>> ~[0,0] is more useful.
>
> Yes, but it's hard to tell.  As said, anti-ranges quickly degrade in
> further propagation and I fear that without a better range
> representation it's hard to do better in all cases here.  The fact is
> we can't represent the result of the intersection and thus we have to
> conservatively choose an approximation.  Sometimes we have the other
> range on an SSA name and thus can use equivalences (when coming from
> assert processing), but most of the time not and thus we can't use
> equivalences (which use SSA name versions rather than an index into
> a ranges array - one possible improvement to the range
> representation). Iff ~[0,0] is useful information querying sth for
> non-null should also look at equivalences btw.
I spoke with Andrew a bit today, he's consistently seeing cases where 
the union of 3 ranges is necessary to resolve the kinds of queries we're 
interested in.  He's made a design decision not to use anti-ranges in 
his work, so y'all are in sync on that long term.

He and Aldy have some bits to change the underlying range representation 
that might make sense to hash through right after stage1 reopens.

Jeff