From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by sourceware.org (Postfix) with ESMTPS id 291B7385E823 for ; Thu, 6 May 2021 16:54:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 291B7385E823 Received: by mail-qt1-x831.google.com with SMTP id a18so4517680qtj.10 for ; Thu, 06 May 2021 09:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R+vjTGHnVUAcgNrhLgdOW5wcPcagYkxkwXW7QWuBlS0=; b=QWAo5AwkziAWE4ou6+/XeubJTEvosTIIbkiWcd0wR6vyKlK2cXYu0rF1VB+EWpO+bv aC4qt0ezzuc0995cVKX5XDfq0GmG3moezWs/qXS+fjKp4wbg5RRvedDNMlvis0whIrOk YuxDp00DHC92ekWbdwy9sV4TpQpxhep3TKJTJfBXPIe3VPJBSnnpEcAhFeKICrR9tQL6 fSs77/+D7dZaFlp8YQOvPoPoCAq2VXM8kcsFnHll7s0x8kQiumwQT8J03r3T2hSCXDuQ TGglHt94lOu2YWrcNquDmZmSUCaEg4Uk+nH2wHFbOcliZCVPL+2g+SZyAJKcA3hixfzs +DdQ== X-Gm-Message-State: AOAM532nMXfJEF7G3z+bp8vn2032OEq+bCnXU2V4RnY+STax5qoLiCBx P9hhOzP5ux0BIIWO1PD5qt69WjeFvCosOQ== X-Google-Smtp-Source: ABdhPJx2CaF+/EAGqSQCL8An9mBnkSMEi+VOUzx/wK2uxiEP2jxZLqcJVXOF6bJgA4F2TNpXhSAe/w== X-Received: by 2002:ac8:5806:: with SMTP id g6mr5412019qtg.152.1620320089323; Thu, 06 May 2021 09:54:49 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id c2sm2416077qkk.2.2021.05.06.09.54.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 May 2021 09:54:49 -0700 (PDT) Subject: Re: [PATCH 1/4] Remove architecture specific sched_cpucount optimizations To: Florian Weimer Cc: Paul Eggert , Adhemerval Zanella via Libc-alpha , crrodriguez@opensuse.org References: <20210329182520.323665-1-adhemerval.zanella@linaro.org> <87a6p9dr9n.fsf@oldenburg.str.redhat.com> <61040ff8-caac-a3d9-91cc-9b445c4e98fd@cs.ucla.edu> <87pmy4gepw.fsf@oldenburg.str.redhat.com> <9a0723f4-82ec-ae41-0304-3dc1af0bb2c0@linaro.org> <87wnsbg6eu.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <6c3cc84c-4e02-d0ec-76ea-461b8a6f4a8c@linaro.org> Date: Thu, 6 May 2021 13:54:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87wnsbg6eu.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 16:54:52 -0000 On 06/05/2021 13:42, Florian Weimer wrote: > * Adhemerval Zanella: > >>> I get that choosing the exact matching builtin for the __cpu_mask type >>> isn't easy, but wouldn't it be safe to use __builtin_popcountll >>> unconditionally? >> >> Using a open-coded routine is slight better for architectures that >> do not have a popcount instruction, since __builtin_popcountll will >> call the libgcc routine). But I hardly think we need that amount >> of micro-optimization for such routine. > > Ahh, and we'll get a check-localplt failure. Hmm. So mention that in > the comment? The check-localplt issue only occurs when using compiler generated symbols if the libgcc function itself calls a glibc symbol (for instance arm div soft-fp might call raise). In this case the call will be local, the issue is more performance-wise.