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.