From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21854 invoked by alias); 19 Apr 2011 11:02:59 -0000 Received: (qmail 21846 invoked by uid 22791); 19 Apr 2011 11:02:58 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,TW_CF,TW_IB,TW_TM,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Apr 2011 11:02:41 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id DE00C8E8CC; Tue, 19 Apr 2011 13:02:39 +0200 (CEST) Date: Tue, 19 Apr 2011 11:30:00 -0000 From: Richard Guenther To: Jan Hubicka Cc: Richard Guenther , Jakub Jelinek , Jason Merrill , Martin Jambor , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661) In-Reply-To: <20110419104801.GJ911@atrey.karlin.mff.cuni.cz> Message-ID: References: <20110418214008.GE17079@tyan-ft48-01.lab.bos.redhat.com> <20110419000653.GG911@atrey.karlin.mff.cuni.cz> <20110419001518.GH911@atrey.karlin.mff.cuni.cz> <20110419101607.GI911@atrey.karlin.mff.cuni.cz> <20110419104801.GJ911@atrey.karlin.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-04/txt/msg01513.txt.bz2 On Tue, 19 Apr 2011, Jan Hubicka wrote: > > On Tue, 19 Apr 2011, Jan Hubicka wrote: > > > > > > Huh. No, I don't think we want to do any "inlining" as part of > > > > folding. At least not if it > > > > is a correctness issue (is it?). Why does the inliner not simply > > > > inline the thunk function > > > > body? > > > > > > Because thunk functions have no bodies in gimple form and are no functions (at > > > the moment) in cgraph sense. > > > > Well, I see thunks as simple forwarders which we can represent with > > a real function with body in gimple. We don't have to _emit_ it > > That is true only for non-variadic thunks. (and we actually generate bodies for > those early, unless target asked us to do otherwise). Sure, Diego once > mentioned that we might have some kind of special thunk_call gimple statement, > but that seems to me that amount of gimple code that would need to handle > thunk_call strictly exceeds amount of IPA code that would need to get past > special kind of functions. > > Also as as we make them regular functions, we need to go all the way through, > as IPA optimizers will happily modify them so simply using existing target > interface instead of cfgexpand later won't help. In a way, with tailcall > support, the target interface is really only interesting for variadic case. > At least for i386. I did not inspect details of implementation of thunks on > all the archs that do asm thunks to be sure. > > > that way later, but at least IPA passes could do regular stmt > > analysis on them and not need any special thunk knowledge (maybe > > apart from making the inliner not inline the forwarding call into > > the thunk itself). > > > > > What IPA infrastructure needs to learn is to handle inlining of those as well > > > as compute proper jump functions. We spoke with Martin on this some time ago, > > > we ought to get this done in 4.7. Thunks are very irritating spcial cases from > > > cgraph POV ;( > > > > And I don't see why they have to be very irritating spcial cases ;) > > Well, becuase of variadic thunks, I think ;) I thought the idea was to use __builtin_va_arg_pack and friends. Of course the inliner would still need to know how to inline such a va-arg forwarder, and we would need a way to expand them (well, or just go the existing special casing). We might need this kind of inliner support anyway because of the partial inlining opportunity in libquantum which is for a varargs function like void foo (...) { if (always-zero-static) return; ... } thus partial inlining would create such a forwarding call. But well, it's just my random 2 cents on the issue ;) Richard.