From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-481298-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18497 invoked by alias); 10 Jul 2018 13:34:20 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 18366 invoked by uid 89); 10 Jul 2018 13:34:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mail-lf0-f68.google.com
Received: from mail-lf0-f68.google.com (HELO mail-lf0-f68.google.com) (209.85.215.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jul 2018 13:34:17 +0000
Received: by mail-lf0-f68.google.com with SMTP id m12-v6so18303868lfc.10        for <gcc-patches@gcc.gnu.org>; Tue, 10 Jul 2018 06:34:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=HWc9BLjePVijCCFTbdNC6ntgyOeDKzRDxdibnEytFns=;        b=mAtgrjV0DrVD1cxeE+rGP0yfhu5pgq/1SmaHQ9Bzofl0Ti4ML2B+gZ6QIuCArRA/DY         OrI48F5Inc2icIi4f/RI/5dDbmwb0NP8E9EMDKr8Y+UOzbdZBCVnDz12ldLcK9aIUcK8         eeKuV9dv1tx0mBgidPppm+68ltC9gI29YHAqVLRc+sYnwVJL97JXIWQMJbvi4kfc8ouO         1qpY/Xy1TLtZjWnuDUYxin+Zu75PvQ6M13VYKyQtV5HH34UXTIjPct4A+HbUJHAqnzp0         Ib1fuB/gz1SkYKoxWh65NJIXlb3n+z0jD7YaZgc+2wpthch94n8iRRmAdFBeTVKBstS0         vpZg==
MIME-Version: 1.0
References: <CAELXzTOijCYcUUuhUjvsXQMDahdYRx4RhHWGjeAAz5FiHRvW+A@mail.gmail.com> <CAFiYyc07h=+N9O5_iZFL_euup1P+8S_c2PoUpWKyH6CS4HMWWg@mail.gmail.com> <20180710132710.GF7166@tucnak>
In-Reply-To: <20180710132710.GF7166@tucnak>
From: Richard Biener <richard.guenther@gmail.com>
Date: Tue, 10 Jul 2018 13:34:00 -0000
Message-ID: <CAFiYyc0SR8TCH4NLRrvhGacyZ0FJMzDvOJQeXKG6ndoy-UVxXw@mail.gmail.com>
Subject: Re: [RFC] Fix recent popcount change is breaking
To: Jakub Jelinek <jakub@redhat.com>
Cc: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>, 	GCC Patches <gcc-patches@gcc.gnu.org>, Jeff Law <law@redhat.com>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00495.txt.bz2

On Tue, Jul 10, 2018 at 3:27 PM Jakub Jelinek <jakub@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