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

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Would be still good to get rid of.  Not sure why we key off in_gimple_form
either.

What we get is branches done in different directions and thus BB reorder
entered
with a different BB order.

Edge frequencies seem to match but BB frequencies are off, somehow differently
scaled.

-;;   basic block 21, loop depth 2, count 0, freq 655, maybe hot
-;;   Invalid sum of incoming frequencies 985, should be 655
+;;   basic block 21, loop depth 2, count 0, freq 3, maybe hot
...
;;   basic block 23, loop depth 2, count 0, freq 720, maybe hot
+;;   basic block 23, loop depth 2, count 0, freq 2, maybe hot

etc. (- is C + is C++) very few edge frequency differences, but those on
backedges for example:

 ;;    pred:       25 [100.0%]  (FALLTHRU,EXECUTABLE)
-;;                26 [91.0%]  (TRUE_VALUE,EXECUTABLE)
-  # ivtmp.72_13 = PHI <0(25), ivtmp.72_14(26)>
-  # ivtmp.75_226 = PHI <0(25), ivtmp.75_192(26)>
...
+;;                26 [80.0%]  (FALSE_VALUE,EXECUTABLE)
+  # ivtmp.73_13 = PHI <0(25), ivtmp.73_14(26)>
+  # ivtmp.76_226 = PHI <0(25), ivtmp.76_192(26)>

it's already that at profile-estimate time (for LU_factor) which also has
2 more basic blocks and 3 more edges for C++ (with the folding thing
"fixed").  Didn't check performance with the folding fixed.