From patchwork Mon Jul 18 14:12:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Matz X-Patchwork-Id: 649545 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rtQ9k5tVxz9s9d for ; Tue, 19 Jul 2016 00:12:42 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=GYnvMUDk; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; q=dns; s=default; b=E57NQwSH+flSjNvm VQYvER5JW27x5us9yVPGVycWd81fhdlBri+3y/pjsrtadA6WRDCfVIv9DXAq0SNz fCU4QAmSmcgfyR7YF+0JA2kZjhyThUhfeiJ8IEbYclpERou7n10utnkZS00E6Q4p efahiU8XO+MR1DMkyOuPq4OB6+M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=default; bh=zzHqGMwQwjN5QjJrLVdXgR Sw/LQ=; b=GYnvMUDkzuWm3OcSOAvSU+OR0PdeLPBrIqhxG4DaUBg3dusAid2iDr HjCsih/sl/VZdaqobzG04xDO8+3skgqoAyOBNuFtwrL7hyiOOIXF5nkSPCZxIUpc n0Ys2BWifpvEQ4/ublPf16gy0P+pJwr/Qs4eUTWTWJufa6BuCE7XU= Received: (qmail 103688 invoked by alias); 18 Jul 2016 14:12:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 103679 invoked by uid 89); 18 Jul 2016 14:12:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS, KAM_STOCKGEN, RP_MATCHES_RCVD, SPF_PASS autolearn=no version=3.3.2 spammy=sk:positio, retain, sk:SYMBOL_, H*Ad:D*cx X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 18 Jul 2016 14:12:19 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D080BAD77; Mon, 18 Jul 2016 14:12:15 +0000 (UTC) Date: Mon, 18 Jul 2016 16:12:15 +0200 (CEST) From: Michael Matz To: Jakub Jelinek cc: Richard Biener , Segher Boessenkool , Patrick Palka , GCC Patches Subject: Shared libbackend.so (was: [PATCH] Avoid invoking ranlib on libbackend.a) In-Reply-To: <20160718123704.GB7387@tucnak.redhat.com> Message-ID: References: <20160718113511.GA32392@gate.crashing.org> <20160718123704.GB7387@tucnak.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 X-IsSubscribed: yes Hi, On Mon, 18 Jul 2016, Jakub Jelinek wrote: > On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote: > > While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is > > when you get rid of the archive or save link time by creating a (partially) > > linked DSO. ISTR Michael Matz has patches to do that. Whether it's > > DSO? Then we'd have to build everything with -fpic (which we only do when > building gccjit). Did you mean just a relocatable object (ld -r) instead? Yes, a real DSO, and yes with -fpic. I had hacks in the compiler to make functions be protected visibility (and only those, as protected data is a PITA) to retain inlining effects to not lose too much performance (and some hackery in binutils to make this work as intended). At that time (years ago) a cc1 with shared libbackend.so was even faster than a static cc1 (!). When dusting off that stuff I realized that -fPIE has similar effects (symbols aren't preemptable, so inlining still happens, and the code is mostly appropriate for a shared object). But I ran into the same binutils artifacts again and haven't found time to really continue with that. Some quick hack in binutils to not error out on direct PC-relative references to data symbols (for fear of copy relocs) shows that a sort-of-shared cc1+libbackend.so is about 1% slower than a static one (on some fold-const.i file I had) on x86-64. These cc1 were built with -O0 and checking enabled. If you want to play with that, attached are two diffs, one for GCC, one for binutils. configure with --enabled-backend-shared, and then play with the two BACKENDPICFLAG and NO_PIE_CFLAGS flags (the latter should contain -fPIE so that no copy relocs are created when BACKENDPICFLAGS contains -fvisibility=protected). The binutils hack is only needed if libbackend.so is built with -fPIE. The above timing is with BACKENDPICFLAGS="-fPIE -fvisibility=protected" and NO_PIE_CFLAGS=-fPIE and the binutils hack. I still wanted to reimplement the visibility for functions only flag and remeasure. Then the binutils part wouldn't be necessary. Ciao, Michael. diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c index e80fd20..94b4680 100644 --- a/bfd/elf64-x86-64.c +++ b/bfd/elf64-x86-64.c @@ -4520,7 +4520,7 @@ elf_x86_64_relocate_section (bfd *output_bfd, || r_type == R_X86_64_PC32_BND) && is_32bit_relative_branch (contents, rel->r_offset)); - if (SYMBOL_REFERENCES_LOCAL (info, h)) + if (SYMBOL_CALLS_LOCAL (info, h)) { /* Symbol is referenced locally. Make sure it is defined locally or for a branch. */