Weird, but cc @scottmcm as the author of #123949.

One side effect of the PR in question is that it changes how aggressive the MIR inliner is. Since you've also commented that you have long callchains with lots of small functions, I suspect that the performance of your code is highly sensitive to inlining.

If I'm right, you can emulate this effect on 1.78 by increasing the MIR inlining thresholds. The defaults are -Zinline-mir-forwarder-threshold=30 -Zinline-mir-hint-threshold=100 -Zinline-mir-threshold=50. Adding 10 or 20 to all those numbers is the kind of experiment I'd try.

Similarly, you could try turning the MIR inliner off in 1.79 with -Zinline-mir=no.

But if the relevant optimization difference is in the precompiled standard library, you'd need to do all this with -Zbuild-std which will itself be a whole mess because the precompiled one is built with debuginfo = 2, and you aren't using that for your benchmarks.

There is really not a lot we can do without a reproducer, and even with one if this boils down to "this code requires a specific MIR inliner behavior", we are likely to take action only if that can be extracted to an inliner heuristic that can stand on its own merits.

Huh, when I heard "long callchains with lots of small functions" I was expecting this to be caused by #127113, not by #123949.

I agree with Ben that it's really hard to do anything without a reproducer, though. All the complicated interactions between the MIR inliner and LLVM's inliner here make any change really hard to predict what it will actually do, and all the thresholds mean that tiny changes sometimes have no effect, and sometimes have knife-edge effects.

(Sorry didn't notice this was open 12 hours ago)