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:
I'd like to see gimple-ssa-array-bounds invoked from the access
pass too (instead of from VRP), and eventually -Wrestrict as well.
You can do that right now. The pass has been converted to the new API
and it would just require calling it with a ranger instead of the
vr_values from VRP:
array_bounds_checker array_checker (fun, &vrp_vr_values);
array_checker.check ();
That is, move it where you want and pass it a fresh new gimple_ranger.
If there are any regressions, we'd be glad to look at them.
I appreciate that and I'm not worried about regressions due to
ranger code.
It's not so simple as it seems because of the optimizer
dependencies I mentioned. -Warray-bounds runs before vectorization
and the access pass after it. Moving it into the access pass will
mean dealing with the fallout: either accepting regressions in
the quality of warnings (bad locations due to vectorization
merging distinct stores into one) or running the access pass at
a different point in the pipeline, and facing regressions in
the other warnings due to that. Running it twice, once earlier
for -Warray-bounds and then again later for -Wstringop-overflow
etc, would be less than optimal because they all do the same
thing (compute object sizes and offsets) and should be able to
share the same data (the pointer query cache). So the ideal
solution is to find a middle ground where all these warnings
can run from the same pass with optimal results.
-Warray-bounds might also need to be adjusted for -O0 to avoid
warning on unreachable code, although, surprisingly, that hasn't
been an issue for the other warnings now enabled at -O0.
All this will take some time, which I'm out of for this stage 1.
I'm not sure about the strlen/sprintf warnings; those might need
to stay where they are because they run as part of the optimizers
there.
(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 wan:
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!
Martin
