https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
Bug ID: 103585
Summary: fatigue2 requires inlining of peridida to work well
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
fatigue2 regresses by 35% comparing -Ofast -march=native (zen) to -Ofast
-march=native -fno-inline-functions-called once
In generall inlining functions called once is not intended as important
performance heuristics. Here we seem to miss some propagation that supports
better vectorization.
The important inline is:
-Inlining perdida.constprop/105 size 703.
- Called once from iztaccihuatl/17 2570 insns.
- Parm map: -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4 -4
-Updated mod-ref summary for iztaccihuatl/17
- loads:
- Every base
- stores:
- Base 0: alias set 6
- Ref 0: alias set 6
- Every access
- Side effects
- Global memory read
- Inlined into iztaccihuatl/17 which now has 3148 size
-Overall time estimate: 270429.808105 weighted by profile: 0.000000
+Overall time estimate: 93562.854248 weighted by profile: 0.000000
So we estimate it to 703 instructions that is not small and the function
inlined to is already quite large (3148 instructions).
Before vectorizer the perdida is still 800 lines of gimple dump (w/o
declarations) but then it simplifies to 630 at the last rerun of dse.
iztaccihuatl is 3323 lines of gimple dump in .optimized of build with perdida
inlined 2832 in build without perdida inlined, so 491 lines. So it looks like
indeed something propagates with we do not get from ipa-cp/modref propagation.
