From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19515 invoked by alias); 27 Jun 2011 13:45:02 -0000 Received: (qmail 19407 invoked by uid 22791); 27 Jun 2011 13:45:01 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jun 2011 13:44:46 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 5106D87D82; Mon, 27 Jun 2011 15:44:45 +0200 (CEST) Date: Mon, 27 Jun 2011 14:08:00 -0000 From: Richard Guenther To: Jan Hubicka Cc: "H.J. Lu" , gcc-patches@gcc.gnu.org, dnovillo@google.com, jakub@redhat.com Subject: Re: varpool alias reorg In-Reply-To: <20110624123045.GC3591@kam.mff.cuni.cz> Message-ID: References: <20110618083233.GA22220@kam.mff.cuni.cz> <20110623163834.GA3591@kam.mff.cuni.cz> <20110624110601.GD3783@kam.mff.cuni.cz> <20110624123045.GC3591@kam.mff.cuni.cz> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2011-06/txt/msg01990.txt.bz2 On Fri, 24 Jun 2011, Jan Hubicka wrote: > Hi, > this is yet another variant of the fix. This time we stream builtins decls as > usually, but at fixup time we copy the assembler names (if set) into the > builtin decls used by folders. Not sure if it is any better than breaking > memops-asm, but I can imagine that things like glibc actually rename string > functions into their internal variants (and thus with this version of patch we > would be able to LTO such library, but still we won't be able to LTO such > library into something else because something else would end up referncing the > internal versions of builtins). I doubt we could do any better, however. Not stream builtins with adjusted assembler names (I guess we'd need a flag for this, DECL_USER_ASSEMBLER_NAME_SET_P? Or just check for attributes?) as builtins but as new decls. Let lto symbol merging then register those as aliases. But which way around? probably similar to how we should handle re-defined extern inlines, the extern inline being the GCC builtin and the re-definition being the aliased one. > __attribute__ ((used)) is still needed in memops-asm-lib.c because LTO symtab > of course doesn't see the future references to builtins that we will emit > later via folding. I think it is resonable requirement, as discussed at the > time enabling the plugin. Yes, I think the testcase fix sounds reasonable. I suppose you can come up with a simpler testcase for this "feature" for gcc.dg/lto highlighting the different issues? I'm not sure if we are talking about my_memcpy () alias("memcpy") or memcpy () alias("my_memcpy"). I still like to stream unmodified builtins as builtins, as that is similar to pre-loading the streamer caches with things like void_type_node or sizetype. Richard.