On Wed, 1 Jul 2026, Jeffrey Law wrote:
>
>
> On 7/1/2026 9:43 AM, Kyrylo Tkachov wrote:
> >> 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.
> Yea, that's sounds more like a random downstream effect than something
> intentional. I don't really recall split-path-6, though a reasonable
> assumption would be that I was playing around with the original patch and
> included some tests I found when experimenting with the patch's behavior.
Can we preserve testcases as compile-only btw? Some might have been
introduced for ICEs, some for overall expected optimization (with
no path splitting).
Richard.
>
> Jeff
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald; (HRB 36809, AG Nuernberg)
