From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28428 invoked by alias); 28 Jun 2013 13:01:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28322 invoked by uid 48); 28 Jun 2013 13:00:57 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/36041] Speed up builtin_popcountll Date: Fri, 28 Jun 2013 13:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg01759.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041 --- Comment #24 from Jakub Jelinek --- (In reply to Marc Glisse from comment #23) > (In reply to Jakub Jelinek from comment #18) > > I think it is a bad idea to introduce the IFUNC into libgcc_s, because then > > while you speed up the few users of this builtin, you slow down all users of > > libgcc_s (pretty much all C++ programs and lots of C programs), because they > > will need to resolve the ifunc. > > Do you have a pointer to some text that explains this cost? I tried to read > a bit, but it seems to me that unless you use LD_BIND_NOW, the ifunc won't > be resolved if it isn't called. And if it is called, the main cost compared > to a normal relocation should be the feature test, which is indeed a bit > long but not that bad, especially since calling popcount once increases a > lot the probability that it will be called again. > > Not that it matters that much, interested distributions could always ship an > sse4 libgcc_s where they replace the implementation of popcount, and best > performance requires changing things before there is even a call to libgcc, > but I'd like to understand when ifunc should be used or avoided (quite a few > glibc functions seem to use ifunc, though they are much more used than > popcount and most have a non-constant complexity). If you use prelink, then everything successfully prelinked is LD_BIND_NOW too (for most relocations without runtime cost, but for ifunc not), and for every IFUNC that requires a .gnu.conflict ifunc relocation that needs to be resolved right away.