https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On October 12, 2018 6:57:44 PM GMT+02:00, "wilco at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 > >Wilco <wilco at gcc dot gnu.org> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |wilco at gcc dot gnu.org > >--- Comment #6 from Wilco <wilco at gcc dot gnu.org> --- >(In reply to rguent...@suse.de from comment #5) >> On Wed, 10 Oct 2018, ktkachov at gcc dot gnu.org wrote: >> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 >> > >> > ktkachov at gcc dot gnu.org changed: >> > >> > What |Removed |Added >> > >---------------------------------------------------------------------------- >> > CC| |ktkachov at gcc >dot gnu.org >> > >> > --- Comment #3 from ktkachov at gcc dot gnu.org --- >> > GCC does disable some pattern recognition with >> > -fno-tree-loop-distribute-patterns, which is implied by >-ffreestanding (used by >> > the kernel). Wouldn't it be consistent to disable this pattern >recognition in >> > that setup as well? popcount is not such a fundamental helper >function like >> > e.g. DImode shifts, after all >> >> I am not against adding a new switch for this (not sure if we really >> should overload -fno-tree-loop-distribute-patterns with this since >> this will disable popcount recognition at anything below -O3). > >Would it not make sense to check that the popcount optab is implemented >and >enabled before using it? Calling a library function that does a similar >loop >will be slower than keeping the original loop. Sure. There's a thread on gcc patches for this.
