[PATCH] Rewrite get_size_range for irange API.
Martin Sebor
msebor@gmail.com
Mon Aug 10 20:27:20 GMT 2020
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
More information about the Gcc-patches
mailing list