From patchwork Mon Jan 30 07:38:34 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 138517 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C21A6B6F67 for ; Mon, 30 Jan 2012 18:39:00 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328513942; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=tl6w3iSa3ZWlAEcK2OZmSGm36mk=; b=bjNGL/CcG/zSvYGWWcqhjvogBHgcbGnjgmRsOwtXVIIWpdU0xZR57LEXNsOC35 E3DpREVx75Am1D1YZU1iLWjNFxGnQAX4Jha5e8DuDjeS+aoQnEBRXZyFzWTqzfjB ESY9aYsGDf/lbLJZI4AZkPr+vPlNO2MA87IAOIsyCj9Ic= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=WnxMYFMdhpdci190gkX7paw65BVFTo7Ul8u3VDBrskhgkwTYznP8pMyzjqeVZf KEoQ/kBoSZiTv6pPTuczGPujSr58Mf6/oTeDMpjr2nz0fI7843WB8ftgX9G1g+kT hVWEAkrNC3Pae/m5Ct9KsHwdY6Om0NacVBAe97udfhlI8=; Received: (qmail 5655 invoked by alias); 30 Jan 2012 07:38:55 -0000 Received: (qmail 5535 invoked by uid 22791); 30 Jan 2012 07:38:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jan 2012 07:38:40 +0000 Received: by eaal12 with SMTP id l12so1205714eaa.20 for ; Sun, 29 Jan 2012 23:38:38 -0800 (PST) Received: by 10.213.10.140 with SMTP id p12mr2564582ebp.79.1327909118860; Sun, 29 Jan 2012 23:38:38 -0800 (PST) Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it. [93.34.182.16]) by mx.google.com with ESMTPS id o49sm20712014eeb.7.2012.01.29.23.38.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 23:38:37 -0800 (PST) Message-ID: <4F2648FA.8040702@gnu.org> Date: Mon, 30 Jan 2012 08:38:34 +0100 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Eric Botcazou CC: Andrey Belevantsev , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR 51505 References: <4F16F628.8030002@ispras.ru> <201201291402.25036.ebotcazou@adacore.com> <201201291609.01855.ebotcazou@adacore.com> In-Reply-To: <201201291609.01855.ebotcazou@adacore.com> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 01/29/2012 04:09 PM, Eric Botcazou wrote: >>> As discussed in Bugzilla, this is the patch implementing Paolo's >>> suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The >>> code assumes there is at most one such note per insn. >> >> That's wrong though and wreaks havoc during reload, e.g.: >> >> (insn 169 60 62 4 (set (reg:TF 158) >> (mem/c:TF (plus:SI (reg/f:SI 101 %sfp) >> (const_int -16 [0xfffffffffffffff0])) [3 S16 A64])) >> 960513-1.c:13 97 {*movtf_insn_sp32} >> (expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp) >> (const_int -16 [0xfffffffffffffff0])) [3 S16 A64]) >> (expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ]) >> (reg:TF 154)) >> (nil)))) >> >> because the REG_EQUIV note disappears behind reload's back and it isn't >> prepared for that. This is the cause of the following regression on SPARC: >> >> FAIL: gcc.c-torture/execute/960513-1.c execution, -Os > > As well as: > > FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 > FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -fomit-frame-pointer > FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -g > FAIL: gcc.c-torture/execute/stdarg-2.c execution, -Os > FAIL: gcc.c-torture/execute/stdarg-2.c > execution, -O2 -flto -flto-partition=none > FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 -flto > > for the exact same reason. Does this help? Paolo 2012-01-30 Paolo Bonzini * df-problems.c (df_kill_notes): Check that the use refers to the note under examination. Index: df-problems.c =================================================================== --- df-problems.c (revision 183693) +++ df-problems.c (working copy) @@ -2814,8 +2814,10 @@ df_kill_notes (rtx insn, bitmap live) { df_ref use = *use_rec; if (DF_REF_REGNO (use) > FIRST_PSEUDO_REGISTER + && DF_REF_LOC (use) && (DF_REF_FLAGS (use) & DF_REF_IN_NOTE) - && ! bitmap_bit_p (live, DF_REF_REGNO (use))) + && ! bitmap_bit_p (live, DF_REF_REGNO (use)) + && loc_mentioned_in_p (DF_REF_LOC (use), XEXP (link, 0))) { deleted = true; break;