On Mon, 2023-12-25 at 10:08 +0800, chenglulu wrote: > > 在 2023/12/24 下午8:59, Xi Ruoyao 写道: > > On Sat, 2023-12-23 at 18:47 +0800, Xi Ruoyao wrote: > > > On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote: > > > > On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote: > > > > > > The performance drop has nothing to do with this patch. I > > > > > > found that the h264 performance compiled > > > > > > by r14-6787 compared to r14-6421 dropped by 6.4%. > > > > Then I guess we should create a bug report... > > > > > > > > > But there is a problem. My regression test has the following > > > > > two fail items.(based on r14-6787) > > > > > +FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) > > > I guess this is https://gcc.gnu.org/PR28123. > > > > > > > > +FAIL: gcc.dg/pr86617.c scan-rtl-dump-times final "mem/v" 6 > > > I'll take a look on this. Maybe it will show up with Binutils > > > trunk (I > > > just realized I tested this patch with Binutils 2.41, and it's not > > > sufficient to really test the change). > > I cannot reproduce the issue on a Gentoo dev machine with Binutils > > 2.41.50.20231218 and the patch on top of r14-6819. And in my manual > > testing (for ruling out the difference caused by default PIE and > > SSP) > > the test also passes: > > > > xry111@nanmen2 ~/git-repos/gcc-build $ /home/xry111/git-repos/gcc- > > build/gcc/xgcc -B/home/xry111/git-repos/gcc-build/gcc/ > > /home/xry111/git- > > repos/gcc/gcc/testsuite/gcc.dg/pr86617.c -fdiagnostics-plain-output > > -Os > > -fdump-rtl-final -ffat-lto-objects -S -o pr86617.s -fno-stack- > > protector > > -fno-pie && grep -c mem/v pr86617.c.348r.final > > 6 > > > > Could you recheck with latest GCC master? > Ok, I'll test again with the latest code.
Per https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641407.html I need to and "&& true" into the split condition. I'll test it and send V2. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
