On 2/8/22 03:25, Richard Biener wrote:
On Mon, Feb 7, 2022 at 3:33 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
This changes the non-null interface to provide more granularity and
facilitate more precise queries.

Previously, we could only ask if NAME was nonnull anywhere in the block,
and it applied to the entire block.  now we can ask:
    bool always_nonnull_p (tree name, basic_block bb);    // all uses are
nonnull in the block
    bool contains_nonnull_p (tree name, basic_block bb); // there is a
nonnull use somewhere in the block.
How is the latter useful?  To me it seems that

   bool nonnull_at_p (tree name, gimple *stmt);
// 'name' is nonnull at the execution of STMT

would be (or nonnull_from_p with starting with STMT), nonnull_from_p could
be overloaded with basic_block even.

I see the patch uses contains_nonnull_p for range_on_exit.  In the previous
patch I commented that for
Huh, I dont see that comment.  but nonetheless...
   <bb5>:
      *p = foo (*q);  // fallthru + EH

on the fallthru edge we know p and q are not NULL but on the EH edge
we only know q is not NULL.  [with -fnon-call-exceptions we have a
representational issue since the *q load might trap but we cannot currenty
separate that EH on GIMPLE]

we bail all over the place if cfun->can_throw_non_call_exceptions is true anyway.



So given that wouldn't we instead need range_on_edge () instead of
range_on_exit?  At least contains_nonnull_p cannot be used for
range_on_exit in case we derive nonnull from *p?


Btw, for -fnon-call-exceptions all ranges derived from the possibly throwing
stmt are not realized on the exceptional path.  Like for

  <bb6>:
     _1 = _3 / _5;  // fallthru + EH

on the fallthru edge we have _5 ~[0,0] but on the EH edge we do not
(in fact there we have _5 equals to [0,0] in this specific case).

Short-term it might be neccessary to not derive ranges from a
stmt that throws internally but it would be nice to sort those issues
out?

yes.

So, range_on_exit is only ever called from range_on_edge. You are suggesting that I move the adjustment from range_on_exit into range_on_edge and guarded with
!(e->flags & EDGE_EH)
Thats pretty straightforward.


Andrew


Reply via email to