On 10/15/26 9:39 AM, Kyrylo Tkachov wrote:
Yes, we can do that. We’d need to take into account:
- On targets without a length attribute, get_attr_min_length returns 0. Then
--param=max-goto-duplication-insns does not limit the copies, and 0 does not
disable them. Computed gotos already behave like this. I would count one unit
per insn on such targets.
Given computed gotos already behave this way, I'm comfortable with this.
- hw-doloop (arc, bfin, c6x, xtensa) must not redirect a hardware-loop entry
edge that comes from a shared table.
Ugh. That didn't even cross my mind. I thought ppc had a low overhead
looping mechanism as well.
- When every predecessor takes a copy, the original dispatch is deleted and its
table can end up last in the function. alpha and ia64 look for a final call or
trap with prev_active_insn, and the ia64 stop-bit code expects the insn before
a table to be its jump. These must handle such a table. Or we opt these targets
out initially ;)
Opt them out if you go that way. My hope was opt-out would be a small
amount of work on your side, we throw the kit into my tester to catch
things we missed, then move on.
I can flesh out the tests in the next revision.
It never really occurred to me, does this muck up loop structure? I guess it's
running late enough to not matter. So call it curiosity rather than a review
concern.
There is no loop structure to update at that point. compgotos runs after
the RTL loop passes have cleared PROP_loops and freed the loop tree.
OK. Thanks for confirming.
On AArch64 the exception was selective
scheduling with pipelining. It tried to create preheaders for those
small loops by redirecting shared-table edges. That is why patch 1
makes is_cfg_nonregular reject shared tables, and switch-dispatch-7.c
covers it. Under opt-out, hw-doloop is a second case (see above).
I'd like to kill selective scheduling. It's been a buggy mess and I
consider it effectively unmaintained at this point, but that's another
can of worms you probably don't want to open.
jeff
