Re: [PATCH] Try to resolve paths in threader without looking further back.

[Aldy Hernandez <aldyh@redhat.com>]

On 10/22/21 5:59 PM, Martin Sebor wrote:
> On 10/22/21 9:18 AM, Aldy Hernandez wrote:
>> On Fri, Oct 22, 2021 at 4:27 PM Martin Sebor <msebor@gmail.com> wrote:
>>>
>>> On 10/22/21 5:22 AM, Aldy Hernandez wrote:
>>>> On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor <msebor@gmail.com> wrote:

>>>>> (By the way, I don't see range info in the access pass at -O0.
>>>>> Should I?)
>>>>
>>>> I assume you mean you don't see anything in the dump files.
>>>
>>> I mean that I don't get accurate range info from the ranger
>>> instance in any function.  I'd like the example below to trigger
>>> a warning even at -O0 but it doesn't because n's range is
>>> [0, UINT_MAX] instead of [7, UINT_MAX]:
>>>
>>>     char a[4];
>>>
>>>     void f (unsigned n)
>>>     {
>>>       if (n < 7)
>>>         n = 7;
>>>       __builtin_memset (a, 0, n);
>>>     }
>>
>> Breakpoint 5, get_size_range (query=0x0, bound=<ssa_name
>> 0x7fffe9fefdc8 1>, range=0x7fffffffda10,
>>      bndrng=0x7fffffffdc98) at
>> /home/aldyh/src/gcc/gcc/gimple-ssa-warn-access.cc:1196
>> (gdb) p debug_ranger()
>> ;; Function f
>>
>> =========== BB 2 ============
>> Imports: n_3(D)
>> Exports: n_3(D)
>> n_3(D)    unsigned int VARYING
>>      <bb 2> :
>>      if (n_3(D) <= 6)
>>        goto <bb 3>; [INV]
>>      else
>>        goto <bb 4>; [INV]
>>
>> 2->3  (T) n_3(D) :     unsigned int [0, 6]
>> 2->4  (F) n_3(D) :     unsigned int [7, +INF]
>>
>> =========== BB 3 ============
>>      <bb 3> :
>>      n_4 = 7;
>>
>> n_4 : unsigned int [7, 7]
>>
>> =========== BB 4 ============
>>      <bb 4> :
>>      # n_2 = PHI <n_3(D)(2), n_4(3)>
>>      _1 = (long unsigned int) n_2;
>>      __builtin_memset (&a, 0, _1);
>>      return;
>>
>> _1 : long unsigned int [7, 4294967295]
>> n_2 : unsigned int [7, +INF]
>> Non-varying global ranges:
>> =========================:
>> _1  : long unsigned int [7, 4294967295]
>> n_2  : unsigned int [7, +INF]
>> n_4  : unsigned int [7, 7]
>>
>>  From the above it looks like _1 at BB4 is [7, 4294967295].
> 
> Great!
> 
>>   You probably want:
>>
>>    range_of_expr (r, tree_for_ssa_1, gimple_for_the_memset_call)
> 
> That's what the function does.  But its caller doesn't have
> access to the Gimple statement so it passes in null instead.
> Presumably without it, range_of_expr() doesn't have enough
> context to know what BB I'm asking about.  It does work
> without the statement at -O but then there's just one BB
> (the if statement becomes a MAX_EXPR) so there's just one
> range.
> 
>>
>> BTW, debug_ranger() tells you everything ranger would know for the
>> given IL.  It's meant as a debugging aid.  You may want to look at
>> it's source to see how it calls the ranger.
> 
> Thanks for the tip.  I should do that.  There's a paradigm
> shift from the old ways of working with ranges and the new
> way, and it will take a bit of adjusting to.  I just haven't
> spent enough time working with Ranger to be there.  But this
> exchange alone was already very helpful!


You can query the ranger on any point in the IL.  However, if you don't 
give it context, it'll just return the globally known range.  In this 
case it'll be the global SSA range, which is unset because the usual 
setters haven't run at -O0 (evrp, VRP*).  So yes, you need to pass it 
correct context.

Yes, it's a paradigm shift.  The evrp engine worked by pushing state as 
you did a dom walk, so you could ask for SSA ranges that were specific 
to the path sensitive point you were in the walk.  The ranger is far 
more versatile, in which you can ask for a range on an edge, block, or 
statement, regardless of how you're iterating through the gimple.

You can also use the ranger to indirectly tell you about reachability. 
For example, if you ask for the range of x_6 at a point in the IL and 
the answer comes out as UNDEFINED, that point is unreachable.  That is, 
assuming x_6 is considered live at the query point.  IIRC, if you ask 
for x_6  at a point not dominated by the definition of x_6, the ranger 
will also return UNDEFINED.

The ranger API is designed to be minimal and simple:

bool range_of_stmt (irange &r, gimple *, tree name = NULL);
bool range_of_expr (irange &r, tree name, gimple * = NULL);
bool range_on_edge (irange &r, edge e, tree name);
void range_on_exit (irange &r, basic_block bb, tree name);

Andrew keeps threatening he'll write up some articles this year on the 
ranger and its reusable components. *prod* :)

Aldy