On 7/1/2026 1:42 AM, Richard Biener wrote:
On Wed, 1 Jul 2026, [email protected] wrote:
From: Kyrylo Tkachov <[email protected]>
pass_split_paths duplicates the join block of an IF-THEN-ELSE that feeds a
loop latch, splitting the two paths to the backedge. It runs only at -O3.
In practice it interacts badly with later optimizations: it duplicates the
loop body before loads have been commoned and before if-conversion runs, so
it can block both loop unrolling (PR120892) and if-conversion of the
duplicated diamond, while its own heuristic already declines about half of
all candidate blocks, most often to avoid spoiling if-conversion.
Remove the pass and deprecate the -fsplit-paths option. The option is kept
accepted for backward compatibility via the Ignore flag and now does nothing,
matching how other optimization options have been retired (for example
-ftree-lrs). param_max_jump_thread_duplication_stmts is retained as it is
shared with the jump-threading passes.
Statistics from the pass on SPEC CPU 2026 (intrate + fprate, counted from the
split-paths dump):
candidates splits declined to protect if-conversion
-O3 122894 62050 60844 37166
-O3 -flto=auto 52423 21257 31166 21822
The pass splits about half of the blocks it considers and declines the rest,
most often to avoid spoiling if-conversion. The duplication grows .text by
0.32% at -O3 and 0.24% at -O3 -flto=auto.
Andrea and Jeff indicated in PR120892 that removing -fsplit-paths may be
the way to go there.
-fsplit-paths also complicates the control-flow and defeats the
load-commoning necessary to get good if-conversion of the hot loop from
Snappy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125557#c13 .
Any thoughts on removing it?
ISTR the pass was added to remove a dynamic branch. Arguably this kind
of transform might be better done by RTL BB reorder (which also
understands to duplicate some blocks, but in a very limited way).
IIRC there was the idea of 2nd-order expression simplifications from
the path duplication, but that was a secondary concern.
It was something in coremark based on the test names IIRC and I think at
least part of it was supposed to expose more CSE opportunities or some
such. I did the best I could to extract tests that might be relevant
when it went in. It was always of dubious value. So if we're
regression clean on x86/aarch, then I'm all for it.
What I would suggest would be to look at the code we generate for the
split-paths tests before/after removal and make sure we're not missing
something. The tests, more likely than not, test that split-paths
triggered rather than looking at the final assembly codes.
Jeff
