From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102049 invoked by alias); 8 May 2015 19:35:03 -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 102039 invoked by uid 89); 8 May 2015 19:35:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham 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; Fri, 08 May 2015 19:35:02 +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 t48JYvaD023006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 8 May 2015 15:34:57 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48JYsOx009302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 May 2015 15:34:56 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t48JYq4r022258; Fri, 8 May 2015 21:34:53 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t48JYl29022257; Fri, 8 May 2015 21:34:47 +0200 Date: Fri, 08 May 2015 19:35:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: David Edelsohn , Steve Ellcey , Martin =?utf-8?B?TGnFoWth?= , Jan Hubicka , GCC Patches , Ramana Radhakrishnan , Richard Earnshaw Subject: Re: Question about patch for PR bootstrap/65150 (identical functions) Message-ID: <20150508193447.GR1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <554D0A00.4000002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554D0A00.4000002@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00744.txt.bz2 On Fri, May 08, 2015 at 01:09:52PM -0600, Jeff Law wrote: > On 05/08/2015 01:07 PM, David Edelsohn wrote: > >>>>Steve Ellcey wrote: > >> > >>After your change GCC sees that the code for f1 and f2 are identical > >>so it replaced the body of f2 with a call to f1. This optimization will > >>save space but it is not going to be faster because any call to f2 will > >>now include an extra call/return. Do other platforms have this same issue > >>or is there a way to make f2 an alias for f1 on other targets so no extra > >>call is needed? I looked around to see if there was a target function or > >>macro that is used to make one function an alias of another but I didn't > >>see anything. > > > >This probably is not good for POWER, and probably not for ARM, in fact > >probably not good for most RISC architectures. > But isn't this code going to be creating aliases when the output format > supports them -- which avoids the call/return overheads? > > Which might argue that if we don't have aliases, then ICF might need to be a > -Os thing. ICF uses aliases only when possible (when it can prove that the callers don't care about function address equality/non-equality. In other cases ICF uses caller redirection (if it is possible to redirect all callers and remove unused other call), or thunks (otherwise). Thunks indeed can slow things down somewhat, especially if they can't tail call the function. Jakub