From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10997 invoked by alias); 1 May 2015 18:06:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 10988 invoked by uid 89); 1 May 2015 18:06:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vn0-f42.google.com Received: from mail-vn0-f42.google.com (HELO mail-vn0-f42.google.com) (209.85.216.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 18:06:01 +0000 Received: by vnbf1 with SMTP id f1so10723598vnb.0 for ; Fri, 01 May 2015 11:05:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QiYXa4P+OuJNPIcseEaaiwr/q3VLyxmA1ahxWoIMdao=; b=Xoe+TT/8DlHbhHy4Xd10TDc23b1yww+5lAF5dT+plxhDywKoZ0afjyBQHS3B2rAX2M FE2Dy5XDRwy85NBkPepKw30/8Wv3V60rrAzhPfst6E01YB8ldM7lAIhAinI3JhCOoDMZ F2vC6w5kDv3wPNg7z+kWhYn/REG4kuXlnFyGztebstyryyJe8/Jp8XG0hOaiSG2+DMuu upuuXsdAI49ajjKdMxGoZt+s/1oGIEhEfXUxx5IEN1smamx8/dnd80UUXQsdlyFJqdsK rqtLAYxfaTGhRsZGb6HVKTX0qeRvYNAvUHknd1JYwB6RBzOo/fGpCjvtwmfTcVBsAe1B Wv/g== X-Gm-Message-State: ALoCoQnG1GO7PcpWuHcCNhs4k2K1SpsU6XoxXtGIXlRZ9/kjO/6izat1cVKEUAX4nN219A2OYq06 MIME-Version: 1.0 X-Received: by 10.52.75.99 with SMTP id b3mr14257338vdw.2.1430503558856; Fri, 01 May 2015 11:05:58 -0700 (PDT) Received: by 10.52.121.18 with HTTP; Fri, 1 May 2015 11:05:58 -0700 (PDT) In-Reply-To: References: <87r3r0mjec.fsf@tassilo.jf.intel.com> Date: Fri, 01 May 2015 18:06:00 -0000 Message-ID: Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt= From: Sriraman Tallam To: Xinliang David Li Cc: "H.J. Lu" , Andi Kleen , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00084.txt.bz2 On Fri, May 1, 2015 at 9:26 AM, Xinliang David Li wrote: > yes -- it is good to turn this on by default in LTO mode without > requiring user to specify the option. Yes, with LTO, we would exactly know what the "truly extern" functions are and PLT stubs can be eliminated for all extern functions when early binding is specified. With lazy binding, we can eliminate the PLT stubs selectively for the hot extern functions. Thanks Sri > > David > > On Fri, May 1, 2015 at 9:23 AM, H.J. Lu wrote: >> On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li wrote: >>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote: >>>> Sriraman Tallam writes: >>>>> >>>>> This comes with caveats. This cannot be generally done for all >>>>> functions marked extern as it is impossible for the compiler to say if >>>>> a function is "truly extern" (defined in a shared library). If a >>>>> function is not truly extern(ends up defined in the final executable), >>>>> then calling it indirectly is a performance penalty as it could have >>>>> been a direct call. Further, the newly created GOT entries are fixed >>>>> up at start-up and do not get lazily bound. >>>> >>>> This means you need to make it depend on -fno-semantic-interposition ? >>>> >>>>> Given this, I propose adding a new option called >>>>> -fno-plt= to the compiler. This tells the compiler >>>>> that we know that the function is truly extern and we want the >>>>> indirect call only for these call-sites. I have attached a patch that >>>>> adds -fno-plt= to GCC. Any number of "-fno-plt=" can be specified and >>>>> all call-sites corresponding to these named functions will be done >>>>> indirectly using the mechanism described above without the use of a >>>>> PLT stub. >>>> >>>> The argument seems awkward. The command line may get very long. >>>> Better an attribute? >>> >>> They are complementary. Perhaps another option like linker's >>> --dynamic-list=<> that can take a file specifying the list of symbols. >>> >>>> >>>> Longer term it would be probably better to support it properly >>>> in the linker. >>>> >>> >>> Linker solution has its own downside -- it require reserving more >>> space conservatively for many callsites which end up being direct >>> calls. >>> >> >> Can we do it automatically for LTO? >> >> >> -- >> H.J.