On Sun, 2020-03-08 at 15:53 +0900, Oleg Endo wrote: > On Thu, 2020-03-05 at 08:51 -0700, Jeff Law wrote: > > FWIW I've got an sh4/sh4eb bootstrap and regression test running with > > HONOR_REG_ALLOC_ORDER defined. As Vlad mentioned, that may be a > > viable workaround. > > > > I've had a look at the good old CSiBE code size results and poked at > some of the cases. Overall, it seems to help code quality when > HONOR_REG_ALLOC_ORDER is defined on SH. > > sum: 3383449 -> 3379629 -3820 / -0.112903 % > avg: -212.222222 / -0.271573 % > max: flex-2.5.31 253514 -> 253718 +204 / +0.080469 % > min: bzip2-1.0.2 67202 -> 65938 -1264 / -1.880896 % > > > However, even with HONOR_REG_ALLOC_ORDER defined, the simple test case > from PR 81426 https://gcc.gnu.org/bugzilla/attachment.cgi?id=47159 > fails to compile without -mlra (use options -m4 -matomic-model=soft-gusa on > regular non-linux sh-elf cross compiler). > > How about the bootstrap, Jeff? Did it help anything? Bootstrapped just fine. It neither regressed nor fixed anything in the GCC testsuite -- so it doesn't appear to address the c-torture/compile/sync-1 regression.
Jeff
