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]. You probably wan:
range_of_expr (r, tree_for_ssa_1, gimple_for_the_memset_call)
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.
Aldy
