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

Aldy Hernandez aldyh@redhat.com
Fri Oct 22 15:18:47 GMT 2021


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:
> >
> >> 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



More information about the Gcc-patches mailing list