VRP: allow unsigned truncating conversions that will fit

[Aldy Hernandez]

On 09/14/2018 08:33 AM, Michael Matz wrote:
> Hi,
> 
> On Fri, 14 Sep 2018, Aldy Hernandez wrote:
> 
>> Is there a subtle reason why we're avoiding unsigned truncating conversions of
>> the form:
>>
>> 	[X, +INF]
>>
>> If the X fits in the new type, why can't we just build [X, +INF] in the new
>> type?
> 
> But (uin8_t)((unsigned)[255,+INF]) aka ([255,+INF] & 255) isn't [255,+INF]
> but rather [0,+INF].  What am I missing?  Even considering that the caller
> must canonicalize, I don't see how that would transform [255,+INF] (which
> is a normal range) into [0,+INF].

Ughh, yes.  You're absolutely right.  I was getting confused with how we 
special handled anti-ranges of pointers which make no sense when you 
split them up into it's pieces and try to do the math.  And it made no 
sense because I missed that pointers are actually special and we only 
care about null / non-nullness.

Anyways...ignore the noise.  I have a much cleaner patch to the 
tree-vrp.c conversion code that I'm testing now.

Thanks for your input.
Aldy