On Wed, 11 Sep 2013, Kugan wrote: > Thanks Jakub for the review. > > On 10/09/13 23:10, Jakub Jelinek wrote: > > On Tue, Sep 10, 2013 at 03:17:50PM +0200, Richard Biener wrote: > > > > unsigned short s; > > > > s.1_3 = (short unsigned int) l.0_2; > > > > l.0_2: VARYING > > > > s.1_3: [0, +INF] > > > > > > Note that [0, +INF] is the same as VARYING and [-INF, +INF] and VARYING > > > for > > > l.0_2 is the same as [-INF, +INF]. > > > > Yeah, I don't see much value in differentiating between VR_VARYING and > > VR_RANGE [TYPE_MIN_VALUE, TYPE_MAX_VALUE] (perhaps a question is what to do > > for types with precisions different from TYPE_MODE's bitsize, if we should > > store for VARYING/UNDEFINED a range of all possible values in the mode). > > Unsigned type will be always >= 0, even if it is VARYING or UNDEFINED. > > What is the valid bit good for? Is it meant just for integrals with > > > 2*HOST_BITS_PER_WIDE_INT precision, which we can't represent in double_int? > > I'd say we just don't want to keep track on the value ranges for those. > > Ok, I will remove the valid. > > > And, do we need to distinguish between VR_RANGE and VR_ANTI_RANGE? > > I mean, can't we always store the range in VR_RANGE format? Instead of > > -[3,7] we'd store [8,2] and define that if the min double_int is bigger than > > max double_int, then it is [min,+infinity] merged with [-infinity,max] range > > (i.e. -[max+1,min-1])? > > > > Ok, I will change this too.
Make sure to add a predicate that can tell whether its an anti-range then. Richard.
