On 10/25/18 4:33 PM, Kugan Vivekanandarajah wrote: > Hi, > > PR87528 showed a case where libgcc generated popcount is causing > regression for Skylake. > We also have PR86677 where kernel build is failing because the kernel > does not use the libgcc (when backend is not defining popcount > pattern). While I agree that the kernel should implement its own > functionality when it is not using the libgcc, I am afraid that the > implementation can have the same performance issues reported for > Skylake in PR87528. > > Therefore, I would like to propose that we disable popcount detection > when we don't have a pattern for that. The attached patch (based on > previous discussions) does this. > > Bootstrapped and regression tested on x86_64-linux-gnu with no new > regressions. We need to disable the popcount* testcases. I will have > to define a effective_target_with_popcount in > gcc/testsuite/lib/target-supports.exp if this patch is OK? > > Thanks, > Kugan > > > gcc/ChangeLog: > > 2018-10-25 Kugan Vivekanandarajah <kug...@linaro.org> > > * tree-scalar-evolution.c (expression_expensive_p): Make BUILTIN POPCOUNT > as expensive when backend does not define it. > > > gcc/testsuite/ChangeLog: > > 2018-10-25 Kugan Vivekanandarajah <kug...@linaro.org> > > * gcc.target/aarch64/popcount4.c: New test. > FWIW, I've been disabling by checking direct_optab_handler elsewhere (number_of_iterations_popcount) in my tester. It may in fact be an old patch from you.
Richi argued that it's the kernel team's responsibility to provide a popcount since they don't link with libgcc. And I'm generally in agreement with that position, though it does tend to generate some friction with the kernel developers. We also run the real risk of GCC 9 not being able to build the kernel which, IMHO, would be a disaster from a PR standpoint. I'd like to hear from others here. I fully realize we're beyond the realm of what is strictly technically correct here from a review standpoint. Jeff
