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.