Hello, On Fri, Oct 09 2026, Pengfei Li wrote: > Hi Martin, > > I noticed ~4.9% performance regression of SPEC CPU 2017 x264 on AArch64 > with PGO after this patch.
For x86_64 this has already been reported as PR 127775. However, the real issue is actually PR 119147, i.e. PGO has been detrimental to the performance of 525.x264_r for a long time, the recent change has only made that even worse. This seems to be true also for the Aarch64 that we track: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=584.377.0&plot.1=583.377.0&plot.2=587.377.0&plot.3=589.377.0&; > After a quick look at the perf data, I saw some IPA-CP specializations > are missing. When I looked into the problem, the main issue appeared to be the one described in PR 119147 - vectorizer not vectorizing the most important loops because they do not iterate enough times, which is true, but the cascading epilogues do help a lot anyway but are not created. When this issue is fixed, we can experiment again to see if the clones simply mitigated that somewhat or whether they brought about some other benefit (I only remember that the benchmark reacted to different cloning decisions very erratically but never was better than the non-PGO case because of the above). I am not sure how Aarch64 differs in this regard, if you could look at the respective optimization dumps there, it may be useful. > I don't fully understand how this patch works, but if I > increase the value of param ipa-cp-profile-runtime-scaling (default 19) > to 21, the benchmark score can recover. > > Could you explain how the default value 19 was chosen? I have examined the behavior of the pass on GCC's cc1plus, on clang from LLVM 21 and on the SPEC CPU 2017 CPUrate suite. I verified that the important cloning opportunities for 505.mcf_r and 548.exchange2_r get roughly the scores as in the non-PGO case (and that they take place). Then I looked at the benchmarks with many opportunities and at the production compilers, particularly cc1plus, so that they do not immediately blow the entire unit-growth budget in the first pass over the call-graph, something that was happening in the case of 525.x264_r too, at least in the LTO+PGO case - so whatever was happening was by accident. I do plan to have another look at this for SPEC CPU 2026 but given PR 125607, the result can easily be that we need to be even more careful. Martin
