On 6/15/2021 12:04 AM, Richard Biener wrote:
On Tue, 15 Jun 2021, Aldy Hernandez wrote:
On 6/14/21 4:04 PM, Richard Biener wrote:
The same issue that arises in PR100934 can happen in the backward
threader now (Aldy?) - we eventually run into mark_irreducible_loops
for non-FSM thread paths checking for paths crossing irreducible
region boundaries.
I haven't been following the above PR, so I may be missing something, but it
seems like you would need to twiddle all users of the path registry, not just
the backwards threader.
Yes, VRP already uses LOOPS_NORMAL, I fixed DOM with the patch for
PR100934. That leaves the backwards threader, so after this change
all consumers should be fixed.
The question was more like if we'd ever run into the code in
mark_threaded_blocks that reads
/* Look for jump threading paths which cross multiple loop headers.
The code to thread through loop headers will change the CFG in ways
that invalidate the cached loop iteration information. So we must
detect that case and wipe the cached information. */
EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
...
we're definitely executing mark_threaded_blocks but we've executed
and pruned all FSM threading paths before.
I suppose I should simply place the assert there and see what happens
when I don't fixup the backwards threader ...
I don't think we'll hit that, at least not directly.
All the backwards threader/FSM bits are handled before we get there.
Of course that may mean we need a similar test earlier.
The fact that the backwards threader/FSM bits are inside
tree-ssa-threadupdate is a historical wart. It uses the registry and
that's about it.
Jeff
