Hi Richard, Ping. Please let me know if the test failure that I mentioned in the mail below can be handled by changing the expected generated code. I am not conversant with arm, and hence would appreciate your help.
Regards, Surya On 03/11/23 4:58 pm, Surya Kumari Jangala wrote: > Hi Richard, > I had submitted a patch for review > (https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631849.html) > regarding scaling save/restore costs of callee save registers with block > frequency in the IRA pass (PR111673). > > This patch has been approved by VMakarov > (https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632089.html). > > With this patch, we are seeing performance improvements with spec on x86 > (exchange: 5%, xalancbmk: 2.5%) and on Power (perlbench: 5.57%). > > I received a mail from Linaro about some failures seen in the CI pipeline with > this patch. I have analyzed the failures and I wish to discuss the analysis > with you. > > One failure reported by the Linaro CI is: > > FAIL: gcc.target/arm/pr111235.c scan-assembler-times ldrexd\tr[0-9]+, > r[0-9]+, \\[r[0-9]+\\] 2 > > The diff in the assembly between trunk and patch is: > > 93c93 > < push {r4, r5} > --- >> push {fp} > 95c95 > < ldrexd r4, r5, [r0] > --- >> ldrexd fp, ip, [r0] > 99c99 > < pop {r4, r5} > --- >> ldr fp, [sp], #4 > > > The test fails with patch because the ldrexd insn uses fp & ip registers > instead > of r[0-9]+ > > But the code produced by patch is better because it is pushing and restoring > only > one register (fp) instead of two registers (r4, r5). Hence, this test can be > modified to allow it to pass on arm. Please let me know what you think. > > If you need more information, please let me know. I will be sending separate > mails > for the other test failures. > > Regards, > Surya > > >
