Re: [PATCH] Rewrite get_size_range for irange API.

[Martin Sebor <msebor@gmail.com>]

On 8/10/20 2:08 PM, Andrew MacLeod wrote:
> On 8/10/20 2:46 PM, Martin Sebor wrote:
>> On 8/10/20 11:50 AM, Andrew MacLeod wrote:
>>> On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
>>>> On 8/10/20 5:47 AM, Aldy Hernandez wrote:
>>
>>>
>>> int_range<X> is the type which allows for up to X subranges. 
>>> calculations will be merged to fit within X subranges
>>> widest_irange is the type which allows for "unlimited" subranges... 
>>> which currently happens to be capped at 255.. . (its typedef'd as 
>>> int_range<255>).
>>>
>>> widest_irange is the type used within the range-ops machinery and 
>>> such, and then whatever result is calculated is "toned down" to 
>>> whatever to user provides.
>>>
>>> so if union results in [5,10] and [20, MAX]   and you provide a 
>>> value_range for the result (, or int_range<1>), the result you get 
>>> back will be [5, MAX].. so won't look like there are any multi-ranges 
>>> going on.
>>
>> This is one part of the puzzle (for me).  I don't get [5, MAX] but
>> [0, MAX], on trunk as well as in GCC 10:
>>
>>   void f (unsigned n)
>>   {
>>     if (!((n >= 5 && n <= 10)
>>           || (n >= 20)))        // n2 = [5, 10] U [20, UINT_MAX]
>>       return;
>>
>>     if (n == 3)                 // not folded
>>       __builtin_abort ();
>>   }
>>
>> I'd expect this to get optimized regardless of Ranger (Clang folds
>> the whole function body into a return statement).
>>
> You mean like this? (from our branch.optimized output)  :-)
> 
> f (unsigned int n)
> {
>    <bb 2> [local count: 1073741824]:
>    return;
> }

Sweet!  I want!  ;-) https://www.youtube.com/watch?v=IrCEhRNgGHY

Martin