> On 2 Jul 2026, at 09:00, Richard Biener <[email protected]> wrote: > > 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). >
You mean put them in the torture suite without the scans for expected dump/assembly? Thanks, Kyrill > 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)
