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.

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

Reply via email to