From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 22:38:00 -0000 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 Content-Type: text/plain; charset=ISO-8859-1 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: 2012-11/txt/msg02069.txt.bz2 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)