[PATCH] Rewrite get_size_range for irange API.

[Andrew MacLeod]

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;
}