From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81405 invoked by alias); 1 May 2015 16:23:07 -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 81393 invoked by uid 89); 1 May 2015 16:23:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 16:23:05 +0000 Received: by oign205 with SMTP id n205so73071801oig.2 for ; Fri, 01 May 2015 09:23:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.45.104 with SMTP id l8mr8515664oem.61.1430497383800; Fri, 01 May 2015 09:23:03 -0700 (PDT) Received: by 10.76.54.14 with HTTP; Fri, 1 May 2015 09:23:03 -0700 (PDT) In-Reply-To: References: <87r3r0mjec.fsf@tassilo.jf.intel.com> Date: Fri, 01 May 2015 16:23:00 -0000 Message-ID: Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt= From: "H.J. Lu" To: Xinliang David Li Cc: Andi Kleen , Sriraman Tallam , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00074.txt.bz2 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.