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.
