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.
Thanks,
Sid
