From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21859 invoked by alias); 19 Apr 2011 07:51:34 -0000 Received: (qmail 21850 invoked by uid 22791); 19 Apr 2011 07:51:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Apr 2011 07:51:18 +0000 Received: by wwf26 with SMTP id 26so6331187wwf.8 for ; Tue, 19 Apr 2011 00:51:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.39.66 with SMTP id f2mr5950834wbe.2.1303199477163; Tue, 19 Apr 2011 00:51:17 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Tue, 19 Apr 2011 00:51:17 -0700 (PDT) In-Reply-To: <20110419001518.GH911@atrey.karlin.mff.cuni.cz> References: <20110418214008.GE17079@tyan-ft48-01.lab.bos.redhat.com> <20110419000653.GG911@atrey.karlin.mff.cuni.cz> <20110419001518.GH911@atrey.karlin.mff.cuni.cz> Date: Tue, 19 Apr 2011 08:58:00 -0000 Message-ID: Subject: Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661) From: Richard Guenther To: Jan Hubicka Cc: Jakub Jelinek , Jason Merrill , Martin Jambor , Richard Guenther , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg01490.txt.bz2 On Tue, Apr 19, 2011 at 2:15 AM, Jan Hubicka wrote: >> > Hi! >> > >> > If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically >> > adjusted, but none of the callers are prepared to handle that. >> > Thus, this patch makes devirtualization give up in those cases. >> > >> > Bootstrapped/regtested on x86_64-linux and i686-linux, trunk and 4.6. >> > On the trunk the testcase ICEs before and after the patch in some new = callgraph >> > checking (added today or so, Honza?), on the branch it works just fine. >> >> The ICE for me is: >> jakub.C:77:1: error: a call to thunk improperly represented in the call = graph: >> # VUSE <.MEM_11> >> D.2319_3 =3D D::_ZTv0_n24_NK1D1mEv (&q.D.2159); >> >> void test()/26(14) @0x7ffff77066f0 (asm: _Z4testv) availability:availabl= e analyzed needed reachable body externally_visible finalized >> =A0 called by: int main()/28 (1.00 per call) (can throw external) >> =A0 calls: void bar(int)/1 (1.00 per call) void bar(int)/1 (1.00 per cal= l) virtual int D::m() const/15 (1.00 per call) D::D(const A&)/14 (1.00 per = call) >> =A0 References: >> =A0 Refering this function: >> =A0 has 3 outgoing edges for indirect calls. >> >> this is not my snaity check, but Martins and I think it means that someh= ow your >> change is ineffective on mainline and we still devirtualize. >> Martin, I declare this problem yours. > > Actually what happens here is that CCP devirtualize by propagating the > constructors and due to Richard's new code to drop OBJ_TYPE_REF we finall= y get > a direct call. =A0This is all good and desirable. > > I think good solution would be to fold further and inline the thunk adjus= tment, > just like the type based devirtualization does. =A0Even once I get far en= ough > with my cgraph cleanuping project to make cgraph represent thunks nicely,= we > would win if in these cases ccp and other passes simply inlined the this = adjustment, > like we do with type based devirtualization already. > Martin, I guess it is matter of looking up the thunk info by associated c= graph node > alias and extending fold_stmts of passes that now drop the OBJ_TYPE_REF w= rappers? 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? Richard. > Honza >