From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11543 invoked by alias); 15 Jan 2014 21:17:49 -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 11524 invoked by uid 89); 15 Jan 2014 21:17:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f50.google.com Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 15 Jan 2014 21:17:47 +0000 Received: by mail-qa0-f50.google.com with SMTP id cm18so1397810qab.23 for ; Wed, 15 Jan 2014 13:17:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qa0WPfTcEI8rKzph7MOa6BBFZdcfrEmg3LMicaXGyXQ=; b=gttoLoPYlrLRAQcZtYzXSRjGA5teatdFvnpLM5M6LpFL8bXUPAEhd/t6XxMKfy2haZ fr4yi0LHPld6kfsC7wnvgwMeCuXolH1vSkhryB46pKweRGBgFz+XwHXcg6IzsUbu3EOQ sNVR+vAHuRLuskWMR8gZOa8Y+iQvW5A/tXiEVvHQcNLZRU1yUnCGfwKY0KezkDYuwu42 YQyO4NrRyyoZ6dwIiwGsY9rG/34wNCnUi+ni0HzmRmRiYnlJkCN6ZwMpk9XckdAyytcW WW/kAPI7U6t53EJpsyERGaFbUBKMwSCGFbUm772GfTMklhQHWzI32fnCxtY1XCkfNGrq +v2g== X-Gm-Message-State: ALoCoQnov3mKi2rMTTbOoCo6TniJI3RBxtPMfiKfamqOtF3MK1e51OWkRMfvFP5XwCwJj7RPSARnkXfui692Gtwyv9VWuCPceJUrySVSv2CfwS5I1+bEgHWdCFb0LA/aYwLjUwh6B3uDT6IQuPwEVMZMYT9tLgaEKq14/wrZXcHwNFxGdqHMlDvE5zlIi1OpXfz5ZUTZ2q+yO8c9/THDU0XqqXB9Xu7pjg== MIME-Version: 1.0 X-Received: by 10.229.14.1 with SMTP id e1mr8855825qca.15.1389820665031; Wed, 15 Jan 2014 13:17:45 -0800 (PST) Received: by 10.229.117.65 with HTTP; Wed, 15 Jan 2014 13:17:44 -0800 (PST) In-Reply-To: References: <52D6D76E.5050009@redhat.com> Date: Wed, 15 Jan 2014 21:17:00 -0000 Message-ID: Subject: Re: [PATCH] Fix segfault in FRE during SCC value numbering From: Teresa Johnson To: Jeff Law Cc: "gcc-patches@gcc.gnu.org" , David Li Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00923.txt.bz2 On Wed, Jan 15, 2014 at 12:00 PM, Teresa Johnson wrote: > On Wed, Jan 15, 2014 at 10:46 AM, Jeff Law wrote: >> On 01/15/14 10:07, Teresa Johnson wrote: >>> >>> Handle NULL vdef for call in the case where we have a matching vnresult >>> that has a vdef (it already handles the NULL vdef case when !vnresult). >>> This >>> can happen for promoted indirect calls if the fallback indirect call >>> (which has a vdef) can be proven equivalent to the promoted direct call >>> (which might not have a vdef). >>> >>> This occurred for a case where we had a promoted indirect call, >>> where FRE determined that the promoted direct call and the fall-back >>> indirect >>> call were equivalent (since earlier it determined that the function >>> pointer >>> was always set to that target). The indirect call had been analyzed by >>> visit_reference_op_call first, and had a VDEF. The direct call did not >>> have a >>> VDEF, presumably because it was a leaf function in the same module without >>> any >>> stores. But visit_reference_op_call unconditionally calls set_ssa_val_to >>> when >>> the previous vnresult had a vdef, leading to a seg fault in this case. >>> If we had analyzed the direct call first the failure wouldn't have >>> occurred >>> since the !vnresult case guards the call to set_ssa_val_to with a check >>> for a NULL vdef, and the subsequent handling of the indirect call would >>> also not call set_ssa_val_to since vnresult would have had a null >>> result_vdef. >>> >>> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? >>> >>> 2014-01-15 Teresa Johnson >>> >>> * tree-ssa-sccvn.c (visit_reference_op_call): Handle NULL vdef. >> >> The patch is OK. Given this was an ICE, do you have a reduced test we can >> add to the regression suite? I realize that order of visiting in the SCC is >> important to trigger, but a regression test would still be useful. > > Unfortunately it was hit using LIPO on the google/4_8 branch, and only > occurred with a specific profile. That's why I don't have a trunk test > case. I suppose I could create a test case that has a similar > opportunity. It does look like there are some indirect call promotion > with FDO tests already (e.g. gcc.dg/tree-prof/indir-call-prof.c), but > I'm not sure whether they even trigger the same type of FRE > opportunity. I will take a look. I'm having a hard time getting the right combination of early/late inlining and indirect call promotion on trunk to occur to even allow this optimization to kick in. It's possible I could do so with a sufficiently complicated test, but I'm not sure it is worth it. I'll commit the fix right now though. Thanks, Teresa > > Teresa > >> >> Thanks, >> Jeff >> >> > > > > -- > Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413