On Thu, Feb 19, 2026 at 1:29 PM Siddhesh Poyarekar <[email protected]> wrote: > > On 2026-02-19 03:06, Richard Biener wrote: > > On Thu, Feb 19, 2026 at 5:06 AM Siddhesh Poyarekar <[email protected]> > > wrote: > >> > >> On 2026-02-18 22:46, Andrew Pinski wrote: > >>>> + /* Skip over inval_bb. */ > >>>> + if (inval_bb != from) > >>>> + for (auto gsi = gsi_start_bb (from); !gsi_end_p (gsi); > >>>> + gsi_next_nondebug (&gsi)) > >>>> + { > >>>> + gimple *stmt = gsi_stmt (gsi); > >>>> + if (gimple_code (stmt) == GIMPLE_ASSIGN > >>>> + && clobvar == gimple_assign_lhs (stmt)) > >>> > >>> I am not sure this is correct, this only works if clobvar does not escape. > >>> I think you need to use the alias oracle here to query if the stmt > >>> clobbers clobvar or not. > >> > >> Ugh, sorry, I don't think I even need that; I had tried to combine the > >> loop in use_after_inval_p with this but that didn't work. Given that we > >> know that the use simply straight-lines into the exit block when this is > >> called, I think we could simply walk through the BBs to determine > >> reachability without looking for intervening clobbers/inits; the > >> intervening statements only show up in loops. I'll test and confirm. > > > > Also is 'clobvar' an SSA name? In that case, when you reach CFG merges, > > you have to translate through PHIs. > > > > If it is not a SSA name and you are looking at memory you can use faster > > traversal of SSA_NAME_DEF_STMT of the VUSEs. > > I think only VAR_DECLs reach here, but it doesn't look like it's needed > at all; I can't think of a test case that does not involve a loop and > would insert a refreshing assignment in between the CLOBBER(eos) and the > use. So I reckon simply walking the CFG should be sufficient. > > >>> Also I don't like introducing an extra walk of the IR . Especially > >>> since this would be O(SUM(STMT,BB)) . > >>> There must be a way to tell quickly if there is a path from BB1 to BB2 > >>> without walking the CFG. > >> I looked but couldn't find one :/ Let me take another look around to > >> see if I find something. > > > > There is none (well, you can walk the CFG only, not stmts). You can do > > quick dominator checks first. > > Ack, the earlier code already does the dominator check as a shortcut, > I'll add a post-dominator check to short-circuit the walk in > can_reach_from as well. > > > IMO when we commit to emit a diagnostic it's OK to spend "unreasonable" > > time to prune it (we can always add sth like a --param to limit the work > > to prune). > FWIW, we haven't committed to emitting the diagnostic yet at this point, > but I'm only walking the CFG now (with a POST_DOMINATOR short-circuit), > so it's OK? I'll send a v2 for review.
Well, it should be the last resort "check" given that it's now bound by the size of the functions CFG - it's not easily possible to bound the CFG walk on either side, apart from stopping at the common dominator (but you should do that). Richard. > > Thanks, > Sid
