[PATCH] Call infer_non_null() directly when checking for non-null.

[Andrew MacLeod]

Of course, one needs the patch...

On 10/28/20 10:04 PM, Andrew MacLeod wrote:
> The ranger currently handles "inferred" non-nulls with a special cache..
>
> inferred ranges are thing like
>
> a_2 = *b_1
>
> the dereference of b_1 implies that any use of b_1 after that 
> statement is non-null  (or a trap would have happened).  The problem 
> is that most ranges are calculated as a result of the statement, not 
> as a use.   To deal with that, I created a mini cache for non-nulls.
>
> The first time  a request is made for a pointers range, a quick visit 
> to each use is made to see if that use infers the non-null property, 
> and a bit is set for the block it occurs in. When calculating ranges, 
> this bitmap for the name is consulted during range propagation to see 
> if a range is actually non-null
>
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 is trapping because 
> an interesting sequence of events is happening which results in a stmt 
> which is in the middle of being adjusted has a query made in-flight, 
> and , well, boom. a PR happens.
>
> The routine I was calling infer_value_range()  was doing more work 
> than the cache requires, and some of this extra work was looking 
> closely at the stmt... and the stmt wasnt valid gimple at the time. It 
> turns out, the cache doesnt need this extra work, and its actually 
> easier to simply call the routine we really want directly.
>
> On a side note, going into the next stage 1, I plan to replace this 
> approach with a more generalize solution that has been briefly mentioned.
> We can add another API entry point to range-ops and the ranger to deal 
> with side effects.  currently we can ask for
> 1) the range ON (before) a stmt is executed  (range_of_expr)
> 2) the range ON an edge
> 3) the range OF a stmt (the result of the stmt)
>
> I want to add a more generalized version of 3 which would be range 
> AFTER stmt   which works for things other than the result of a stmt...
> .4) range_after_stmt   which would include things like the dereference:
>
> a_2 = *b_1      // range after would provide  b_1 = [1, +INF]
> d_4 = f_4 / g_8    // range after would provide g_8 = ~[0,0]
>
> Regardless... thats months away.  for now this patch avoids calling 
> those things that dont need to be called and bypasses the erroneous 
> in-flight analysis of the stmt.
>
> Bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
> Andrew
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 609.patch
Type: text/x-patch
Size: 3234 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201028/d02d3bc8/attachment-0001.bin>