On Tue, Feb 14, 2017 at 12:19 AM, Jeff Law <l...@redhat.com> wrote: > On 02/07/2017 01:39 AM, Richard Biener wrote: >> >> 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. > > 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.
Ok. I'd also not hard-code the number of union ranges but make the code agnostic. Still the actual implementation might take a #define / template param for an upper bound. > He and Aldy have some bits to change the underlying range representation > that might make sense to hash through right after stage1 reopens. Good. > Jeff
