On Tue, Jul 10, 2018 at 3:27 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote: > > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah > > > Jeff told me that the recent popcount built-in detection is causing > > > kernel build issues as > > > ERROR: "__popcountsi2" > > > [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined! > > > > > > I could also reproduce this. AFIK, we should check if the libfunc is > > > defined while checking popcount? > > > > > > I am testing the attached RFC patch. Is this reasonable? > > > > It doesn't work that way, all targets have this libfunc in libgcc. This > > means > > the kernel has to provide it. The only thing you could do is restrict > > replacement of CALL_EXPRs (in SCEV cprop) to those the target > > natively supports. > > Yeah, that is what we've done in the past in other cases, e.g. PR82981 > is somewhat similar. So perhaps just check the optab and use it only if it > is supported?
Btw, given that we do not want to fail niter analysis we'd have to audit all places that eventually code-generate it which isn't only SCEV-cprop ... So not sure if it isn't better to user-control this in a way not depending on target HW support... Richard. > > Jakub