From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81028 invoked by alias); 19 May 2015 19:11:14 -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 80519 invoked by uid 89); 19 May 2015 19:11:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 May 2015 19:11:12 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 729F38EFC2; Tue, 19 May 2015 19:11:11 +0000 (UTC) Received: from anchor.twiddle.net (vpn-229-80.phx2.redhat.com [10.3.229.80]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4JJBADZ004551; Tue, 19 May 2015 15:11:10 -0400 Message-ID: <555B8ACD.20503@redhat.com> Date: Tue, 19 May 2015 19:17:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "H.J. Lu" CC: Rich Felker , Michael Matz , Jan Hubicka , Alexander Monakov , GCC Patches , Uros Bizjak Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC References: <20150515194824.GB14415@kam.mff.cuni.cz> <20150515202319.GE17573@brightrain.aerifal.cx> <20150515204237.GF17573@brightrain.aerifal.cx> <20150515230810.GA73210@kam.mff.cuni.cz> <20150515234403.GG17573@brightrain.aerifal.cx> <20150519180659.GG17573@brightrain.aerifal.cx> <555B87F4.30908@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01746.txt.bz2 On 05/19/2015 12:06 PM, H.J. Lu wrote: > On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote: >> On 05/19/2015 11:06 AM, Rich Felker wrote: >>> I'm still mildly worried that concerns for supporting >>> relaxation might lead to decisions not to optimize code in ways that >>> would be difficult to relax (e.g. certain types of address load >>> reordering or hoisting) but I don't understand GCC internals >>> sufficiently to know if this concern is warranted or not. >> >> It is. The relaxation that HJ is working on requires that the reads from the >> got not be hoisted. I'm not especially convinced that what he's working on is >> a win. >> >> With LTO, the compiler can do the same job that he's attempting in the linker, >> without an extra nop. Without LTO, leaving it to the linker means that you >> can't hoist the load and hide the memory latency. >> > > My relax approach won't take away any optimization done by compiler. > It simply turns indirect branch into direct branch with a nop prefix at > link-time. I am having a hard time to understand why we shouldn't do it. I well understand what you're doing. But my point is that the only time the compiler should present you with the form of indirect branch you're looking for is when there's no place to hoist the load. At which point, is it really worth adding a new relocation to the ABI? Is it really worth adding new code to the linker that won't be exercised often? r~