From patchwork Sun Nov 25 22:37:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 201580 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 9EACC2C0084 for ; Mon, 26 Nov 2012 09:38:51 +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=1354487932; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: MIME-Version:Received:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=ma+tH1s6GFVUGi8x/3I7XAjyFYI=; b=lTl+0dzViUoMXui hYs5DBo4qPRs4GW9+QDJq9qcohktiiCpz8W5rJJscAD78T/vqgUIbvFO/Z1rPJo9 ljy/XDdxl21Qxc0EwmR64U6rRtjQh2XKcpbTgChJlz5aMNRYK1vbopyKqCzNE4Gc j6r9VkVRezeqLE5y4FF/lw2FmchI= 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:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Gu/40xuko/y/MjtEtYRwfC/x6+xLjXouZ35TLZleckW3ryQrbTb62NPrFn7ZAS t8uaY/umrxnfcpnnjyHpr30suwoSUM9itDGYSIG6ni93G/F8uvbr3Fi7aXWDRw68 VaJMS4RSxiElQY15XX4kjiH3NZY6K1gBsyvP9/VstYdqA=; Received: (qmail 8378 invoked by alias); 25 Nov 2012 22:38:48 -0000 Received: (qmail 8368 invoked by uid 22791); 25 Nov 2012 22:38:47 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Nov 2012 22:38:40 +0000 Received: by mail-la0-f47.google.com with SMTP id u2so8146604lag.20 for ; Sun, 25 Nov 2012 14:38:38 -0800 (PST) Received: by 10.152.108.42 with SMTP id hh10mr9147607lab.4.1353883118503; Sun, 25 Nov 2012 14:38:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.99 with HTTP; Sun, 25 Nov 2012 14:37:58 -0800 (PST) In-Reply-To: References: <20121118231540.726263BABA@mailhost.lps.ens.fr> <1389549.cran3k5zj2@polaris> <4056318.TDNxM06g4J@polaris> From: Steven Bosscher Date: Sun, 25 Nov 2012 23:37:58 +0100 Message-ID: Subject: Re: Fix twolf -funroll-loops -O3 miscompilation (a semi-latent web.c bug) To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Dominique Dhumieres , bonzini@gnu.org, hubicka@ucw.cz X-IsSubscribed: yes 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 Sun, Nov 25, 2012 at 9:44 PM, Steven Bosscher wrote: > On Sat, Nov 24, 2012 at 2:09 AM, Steven Bosscher wrote: >> On Fri, Nov 23, 2012 at 11:45 PM, Steven Bosscher wrote: >>> Removing the note is easier but it may hurt optimization later on: >>> CSE2 puts the note back in but this introduces a pass ordering >>> dependency. Perhaps that's not a big problem, but I'm not sure... >> >> Hmm, actually CSE2 fails to put the note back, I guess because it's a >> local CSE pass only... > > Here's another possible fix: Just punt on all REG_EQUAL notes for the > IV. It's a bit of a big hammer, but there are no code changes in my > set of cc1-i files (compiled with -funroll-loops) on x86_64 and > powerpc64 so apparently it's not all that important to keep the notes. > > Comments on this one? Or rather this one. Same hammer, different color. It turns out that the rtlanal.c change caused problems, so I've got to use a home-brewn equivalent of remove_reg_equal_equiv_notes_for_regno... Test case is unchanged so I'm omitting it here. Ciao! Steven gcc/ * loop-unroll.c (struct iv_to_split): Add new 'orig_var' member. (analyze_iv_to_split_insn): Record it. (maybe_strip_eq_note_for_split_iv): New function to remove REG_EQUAL notes that refer to IVs that are being split. (apply_opt_in_copies): Use maybe_strip_eq_note_for_split_iv. Twice. Use FOR_BB_INSNS_SAFE. testsuite/ * gcc.dg/pr55006.c: New test. Index: loop-unroll.c =================================================================== --- loop-unroll.c (revision 193394) +++ loop-unroll.c (working copy) @@ -74,6 +74,7 @@ along with GCC; see the file COPYING3. struct iv_to_split { rtx insn; /* The insn in that the induction variable occurs. */ + rtx orig_var; /* The variable (register) for the IV before split. */ rtx base_var; /* The variable on that the values in the further iterations are based. */ rtx step; /* Step of the induction variable. */ @@ -1833,6 +1834,7 @@ analyze_iv_to_split_insn (rtx insn) /* Record the insn to split. */ ivts = XNEW (struct iv_to_split); ivts->insn = insn; + ivts->orig_var = dest; ivts->base_var = NULL_RTX; ivts->step = iv.step; ivts->next = NULL; @@ -2253,6 +2255,32 @@ combine_var_copies_in_loop_exit (struct emit_insn_after (seq, insn); } +/* Strip away REG_EQUAL notes for IVs we're splitting. + + Updating REG_EQUAL notes for IVs we split is tricky: We + cannot tell until after unrolling, DF-rescanning, and liveness + updating, whether an EQ_USE is reached by the split IV while + the IV reg is still live. See PR55006. + + ??? We cannot use remove_reg_equal_equiv_notes_for_regno, + because RTL loop-iv requires us to defer rescanning insns and + any notes attached to them. So resort to old techniques... */ + +static void +maybe_strip_eq_note_for_split_iv (struct opt_info *opt_info, rtx insn) +{ + struct iv_to_split *ivts; + rtx note = find_reg_equal_equiv_note (insn); + if (! note) + return; + for (ivts = opt_info->iv_to_split_head; ivts; ivts = ivts->next) + if (reg_mentioned_p (ivts->orig_var, note)) + { + remove_note (insn, note); + return; + } +} + /* Apply loop optimizations in loop copies using the data which gathered during the unrolling. Structure OPT_INFO record that data. @@ -2293,9 +2321,8 @@ apply_opt_in_copies (struct opt_info *op unrolling); bb->aux = 0; orig_insn = BB_HEAD (orig_bb); - for (insn = BB_HEAD (bb); insn != NEXT_INSN (BB_END (bb)); insn = next) + FOR_BB_INSNS_SAFE (bb, insn, next) { - next = NEXT_INSN (insn); if (!INSN_P (insn) || (DEBUG_INSN_P (insn) && TREE_CODE (INSN_VAR_LOCATION_DECL (insn)) == LABEL_DECL)) @@ -2313,6 +2340,8 @@ apply_opt_in_copies (struct opt_info *op /* Apply splitting iv optimization. */ if (opt_info->insns_to_split) { + maybe_strip_eq_note_for_split_iv (opt_info, insn); + ivts = (struct iv_to_split *) htab_find (opt_info->insns_to_split, &ivts_templ); @@ -2378,6 +2407,8 @@ apply_opt_in_copies (struct opt_info *op ivts_templ.insn = orig_insn; if (opt_info->insns_to_split) { + maybe_strip_eq_note_for_split_iv (opt_info, orig_insn); + ivts = (struct iv_to_split *) htab_find (opt_info->insns_to_split, &ivts_templ); if (ivts)