[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #12)
> Aldy, could you please have a look? Forward jump threading calls
> duplicate_block without checking can_duplicate_block_p — was that supposed
> to work?

[Big caveat here: This is beyond my expertise as I've been careful not to touch
anything dealing with the block copiers in either the backward or the forward
threaders.]

There are two block copiers in tree-ssa-threadupdate.cc
(*_jt_path_registry::update_cfg), one for each of the threader implementations.

It seems the backward one is doing the right thing, because it calls
duplicate_thread_path() which calls can_duplicate_block_p downstream.

For that matter, the ethread pass (backward threader) finds this exact path,
registers it, but then silently drops it because of the checks in
duplicate_thread_path():

  [1] Registering jump thread: (2, 5) incoming edge;  (5, 7) nocopy; 

The forward threader seems to have more ad-hoc ways of determining
threadability, like potentially_threadable_block(), but AFAICT it never checks
can_duplicate_block_p.  I suppose one could just add a can_duplicate_block_p
check to potentially_threadable_block.

But a better approach would be to drop these problematic paths at registration.
 We already have a gate for precisely these things (cancel_invalid_paths), and
it would be shared between both threaders.  Furthermore, it would add a nice
message in the log as to why the path was dropped.

I don't have the cycles to fix this, but I can provide of a proof of concept
that may be enough.