From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19769 invoked by alias); 6 May 2015 15:55:19 -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 19736 invoked by uid 89); 6 May 2015 15:55:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 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; Wed, 06 May 2015 15:55:12 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t46FtB3c017536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 May 2015 11:55:11 -0400 Received: from localhost.localdomain (ovpn-113-143.phx2.redhat.com [10.3.113.143]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t46FtAhw014830; Wed, 6 May 2015 11:55:10 -0400 Message-ID: <554A395E.5020103@redhat.com> Date: Wed, 06 May 2015 15:55:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jakub Jelinek , Alexander Monakov CC: gcc-patches@gcc.gnu.org, Rich Felker Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt References: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> <1430757479-14241-6-git-send-email-amonakov@ispras.ru> <5547AD8D.9080806@redhat.com> <20150504173955.GE1751@tucnak.redhat.com> <5547AF7C.9030500@redhat.com> <20150506154554.GZ1751@tucnak.redhat.com> In-Reply-To: <20150506154554.GZ1751@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00477.txt.bz2 On 05/06/2015 09:45 AM, Jakub Jelinek wrote: > As for hoisting the load of the call address before the loop, with lazy > binding that has the obvious disadvantage that you'd resolve the slot again > and again, if you are unlucky enough that the function hasn't been resolved > yet. Unless the shared PLT stub after computing _G_O_T_ (for x86) also > rechecks the .got.plt address. Yea, but I suspect that's the rare case rather than the common case. Of course, it's so bloody expensive when it happens, it might totally outweigh the aggregated benefits from all the other profitable hoisted GOT loads. jeff