> On 1 Jul 2026, at 16:44, Jeffrey Law <[email protected]> wrote:
>
>
>
> 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.
So out of all split-path tests only one shows a difference with -fsplit-paths
vs -fno-split-paths: split-paths-6.c where -fno-split-paths gives +3 aarch64
instructions, but this is a downstream artifact.
In the source:
void givehelp (int interactive)
{
if (interactive)
while ((--((_impure_ptr->_stdin))->_r < 0
? __srget_r (_impure_ptr, _impure_ptr->_stdin)
: (int) (*((_impure_ptr->_stdin))->_p++)) != ' ‘);
}
-fsplit-paths triggers once but the duplication is later remerged but the edge
probabilities end up different and then loop rotation ends up making different
layout decisions.
So I don’t think it’s a very deliberate effect.
Thanks,
Kyrill
>
> Jeff
