> From: Hans-Peter Nilsson <h...@axis.com> > Date: Fri, 12 Jul 2024 02:11:45 +0200 > > > Date: Wed, 3 Jul 2024 12:46:46 -0600 > > From: Jeff Law <jeffreya...@gmail.com> > > > The late-combine patch has triggered a previously latent bug in reorg. > > > > Basically we have a sequence like this in the middle of reorg before we > > start relaxing delay slots (cris-elf, gcc.dg/torture/pr98289.c) > > [...] > > > Pushing to the trunk momentarily.
JFTR, for cris-elf, this can't be blamed on (to have been exposed by) late-combine, because this appeared with r15-1619-g3b9b8d6cfdf593 "ira: Scale save/restore costs of callee save registers with block frequency", even with -fno-late-combine-instructions. I noticed because I chased another regression, an XPASS, happening for gcc.dg/tree-ssa/loop-1.c which was also caused by that revision. Regarding that commit, checking the generated code for loop-1.c, that XPASS was reflecting a *regression*, not an improvement. To wit, it looks like _foo is no longer stored in a register for cris-elf, but there's no change in the number of saved registers. As coremark results are the same before/after that commit for cris-elf, I'm not going to make a fuss; IOW, not open a PR for the regression. (Phew, one less rabbit-hole. I see that patch exposed as many problems as late-combine!) Still, a heads-up to the author of that patch. Maybe the frequencies are miscalculated for that test-case. I tried to look at regs.h:REG_FREQ_FROM_BB, but it's a mystery to me: its value seems to vary between 1 and 1000, that doesn't seem right, but that macro's used all over the place. Not documented very much though. :( FAOD, not blaming the author of r15-1619-g3b9b8d6cfdf593 here. Also FTR, I had to search a bit to find the patch submission and review. It's in the archives of last October: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631849.html as mentioned in another message. brgds, H-P
