On Tue, Feb 8, 2022 at 3:53 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > 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)
and EDGE_ABNORMAL > Thats pretty straightforward. So yes, if you use nonnull from the dominator for EH/ABNORMAL edges and the anywhere-in-BB nonnull from the fallthru then that would work. But I guess it's easier to exchange the cfun->can_throw_non_call_exceptions checks with stmt_throws_internal () so you don't get ranges from stmts that eventually cause us to go the abnormal/EH edge, then it's valid to use the "rest" of the ranges defined in e->src on those edges as well. > > > Andrew > >
