On Wed, Aug 26, 2026 at 11:50 AM Aldy Hernandez <[email protected]> wrote: > > On Wed, Aug 26, 2026 at 09:28:19AM +0200, Richard Biener wrote: > > On Wed, Aug 26, 2026 at 9:17 AM Richard Biener > > <[email protected]> wrote: > > > > > > On Tue, Aug 25, 2026 at 7:48 PM Aldy Hernandez <[email protected]> wrote: > > > > > > > > The backward threader can resolve a computed goto's target along a > > > > path, but the thread is dropped at copy time when it is the target of > > > > another abnormal edge: > > > > > > > > Registering jump thread: (2, 4) incoming edge; (4, 5) nocopy; > > > > Cannot copy the blocks in the path: Cancelling jump thread: > > > > > > > > The problem is that can_copy_bbs_p refuses any region with an > > > > intra-region abnormal edge by design because it would end up > > > > redirecting abnormal edges which is a no-no. > > > > > > > > Work around this by copying the last block by hand if we know we'll > > > > end up stripping the abnormal flag when we resolve the path. This > > > > allows us to thread paths that end in an abnormal edge, though > > > > abnormal edges mid-path are still disallowed. Though that's not a > > > > regression because AFAICT, DOM won't do that either. > > > > > > > > BTW, I explored various ways of attacking this, and ultimately landed > > > > on the cheapest way to handle this by touching the least amount of > > > > things, cause GCC parts tend to be sticky-- and I don't want to be > > > > left holding the bag ;-). > > > > > > > > Pardon the copious comments and diagrams; I had a hard time wrapping > > > > my head around this. > > > > > > > > OK? > > > > > > Huh, so what's the situation? The last block has a control statement we > > > can statically evaluate but also an abnormal outgoing edge? And the > > > result is a copy of the block but only with the static determined edge? > > > > Ah, computed goto. I think we simply want to allow redirecting of > > abnormal edges, at least on GIMPLE I do not see what is technically > > in the way here. That we reject this might be a defensive measure to > > prevent accidential redirections? As with copying we're happily > > creating new abnormal edges, redirecting those back into the copied > > region looks reasonable. > > > > Honza, didn't you have plans to make this work? > > > > Aldy, does the forward threader handle the testcase or what's the reason > > to try to fix this? > > Yeah, the forward threader handles the testcase just fine, but it > doesn't use the generic copier. It doesn't use copy_bbs at all: it > duplicate_block's one block at a time (leaving the copied edges on the > original destinations) and then remove_ctrl_stmt_and_useless_edges > cleans up. Which is kinda sorta what I'm doing here, just for the > last block of the path.
So I think we should maybe adjust copy_bbs then, for example either by providing a hook to post-process new_bbs[] after copying but before redirecting edges, or by more tailored, specify a BB as exit implicitly by the exit edge that should prevail. I'll note that copy_bbs is a bit generic here, we have a SEME region. That said, adding a "prevailing_exit" argument, and if set, have edges outgoing from prevailing_exit->src copy that are not going to prevailing_exit->dest removed rather than redirected would be sound? Richard. > > The reason to fix the backward threader is so we can drop the DOM > threader, and replace it with a backwards instance after DOM as > discussed. This is one of the regressions that shows up with > --param=dom-jump-threading=0. > > Aldy
