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