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.
