https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #11)
> (In reply to Wilco from comment #10)
> > (In reply to Martin Liška from comment #9)
> > > Taking look at
> > > ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
> > >
> > > The __builtin_popcount is generated from:
> > >
> > > static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> > > {
> > > ...
> > > } else {
> > > for (nchain = 0; rxchain; nchain++)
> > > rxchain = rxchain & (rxchain - 1);
> > > }
> > > ...
> > > }
> > >
> > > It started from r262486. I would that in this situation it's maybe
> > > unexpected that a popcount call will be eventually generated. So I'm for
> > > an
> > > option what will disable the pattern recognition.
> >
> > I'd say this is exactly a case where using a faster popcount instruction
> > helps - if available of course.
>
> Yes, but as seen in PR87528, using a libgcc can slow down a SPEC benchmark.
> But it's related to generic tuning.
>
> >
> > Is there any reason -fno-builtin-popcount can't also block automatic
> > generation of popcount?
>
> Do we really have such option?
None that would work in the way intended.
Note that as I said in the referenced thread a fix could boil down to
adjusting expression_expensive_p to return true if there's no optab
for the builtin/IFN and/or adjusting is_inexpensive_builtin in that way
(with wider effect).
Note that number_of_iterations_popcount might as well create IFN_POPCOUNT
for the case there _is_ an optab. I'm not sure whether we only have/allow
the IFN in case there's an optab.
So let's discuss the efficiency issue in PR87528. PR86677 is really
invalid given you cannot elide providing libgcc.
