On Mon, Feb 6, 2017 at 10:57 PM, Jeff Law <l...@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. Richard. > Jeff
