[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, and this is also another case where we end up with different out-of-SSA
coalescing desires + outcomes.

 Sorted Coalesce list:
-(16562, 0) t_6 <-> t_105
-(16562, 1) ivtmp.101_80 <-> ivtmp.101_81
-(16562, 2) jp_3 <-> jp_107
-(7908, 0) ivtmp.94_76 <-> ivtmp.94_174
-(1640, 0) ivtmp.107_29 <-> ivtmp.107_132
-(1640, 0) ivtmp.113_228 <-> ivtmp.113_229
...
+(3438, 0) ivtmp.74_16 <-> ivtmp.74_17
+(3438, 0) ivtmp.77_192 <-> ivtmp.77_226
+(3312, 0) ivtmp.67_95 <-> ivtmp.67_164
+(1716, 0) t_6 <-> t_105
+(1716, 1) ivtmp.101_80 <-> ivtmp.101_81
+(1716, 2) jp_3 <-> jp_107
+(1638, 0) ivtmp.87_104 <-> ivtmp.87_188
+(961, 0) jj_96 <-> _242
+(820, 0) ivtmp.94_76 <-> ivtmp.94_174

interestingly we have less coalesce fails with fold_build3_loc.  Also edge
frequencies seem to be very different in the end even though we predicted
things the same...

So I still think there's some underlying issue "elsewhere" (apart from
nothing adjusting BB "order" while we still have a CFG around, making
predicted edges fallthrus dependend on whether they are backwards or
forward jumps).