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 <mse...@gmail.com> wrote:
On 10/22/21 5:22 AM, Aldy Hernandez wrote:
On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor <mse...@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
