From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23336 invoked by alias); 28 Jun 2011 08:05:09 -0000 Received: (qmail 23315 invoked by uid 22791); 28 Jun 2011 08:05:06 -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; Tue, 28 Jun 2011 08:04:49 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 60038867E2; Tue, 28 Jun 2011 10:04:47 +0200 (CEST) Date: Tue, 28 Jun 2011 08:34: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: <20110627154815.GB23824@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> <20110627154815.GB23824@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/msg02098.txt.bz2 On Mon, 27 Jun 2011, Jan Hubicka wrote: > > 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 > > Most of code just checks for '*' on begginign of assembler name. I suppose it is safe. > > > 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. > > I don't quite get your answer here. What we do now is: > > 1) stream in builtin as special kind of reference with decl assembler name associated to it > 2) at streaming in time always resolve builtlin to the "official" builtin decls (no matter > what types and other stuff builtin had at stream out time) and overwritting the official builtin > assembler name into one specified. > > What i suggest is > > 1) Stream out builtins as usual decls just with the extra function code > 2) Stream in builtins as usually > 3) optionally set the assembler name of the "official" decl > > I see there are problems with i.e. one decl rule, but we do have same problems > with normal frontends that also do use different decl for explicit builtin > calls than for implicit, sadly. > > I am not quite sure what the proper fix for this problem is - it is very handy > to have builtin decl in middle end where I know it is sane (i.e. it has the > right types etc.). Since C allows to declare the builtins arbitrarily, it gets > bit tricky to preserve one decl rule here. Hm. I would suggest to do as now, stream in builtin specially if it does not have an assembler name attribute. If it does have it, stream it as usually and let lto symtab do its job (I suppose we need to register builtin functions with the symtab as well). > > > __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. > > Doing so will need us to solve the other one decl rules probly. > I didn't really got what the preloading is useful for after all? Saving memory mostly, apart from the special singletons we have (as Micha already hinted). Richard.