From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30032 invoked by alias); 13 Feb 2015 09:16:56 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29954 invoked by uid 48); 13 Feb 2015 09:16:49 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn Date: Fri, 13 Feb 2015 09:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg01451.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 --- Comment #6 from Richard Biener --- (In reply to Jeffrey A. Law from comment #5) > Kirill, you are correct WRT propagation of "b" for "i". Prior to DOM1 we > have: > > ;; basic block 3, loop depth 1, count 0, freq 9100, maybe hot > ;; prev block 2, next block 4, flags: (NEW, REACHABLE) > ;; pred: 7 [91.0%] (TRUE_VALUE,EXECUTABLE) > if (i_1 == b_6(D)) > goto ; > else > goto ; > ;; succ: 4 [0.0%] (TRUE_VALUE,EXECUTABLE) > ;; 5 [100.0%] (FALSE_VALUE,EXECUTABLE) > > ;; basic block 4, loop depth 1, count 0, freq 2, maybe hot > ;; prev block 3, next block 5, flags: (NEW, REACHABLE) > ;; pred: 3 [0.0%] (TRUE_VALUE,EXECUTABLE) > g_x[i_1] = *x1_7(D); > goto ; > ;; succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) > > ;; basic block 5, loop depth 1, count 0, freq 9098, maybe hot > ;; prev block 4, next block 6, flags: (NEW, REACHABLE) > ;; pred: 3 [100.0%] (FALSE_VALUE,EXECUTABLE) > g_x[i_1] = *x2_9(D); > ;; succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) > > > DOM records that i_1 and b_6 are equivalent on the edge bb3->bb4. So in bb4 > it replaces i_1 with b_6. Presumably that's causing problems downstream in > the optimization pipeline. The easiest way to think about this is we record > that i_1 can be legitimately replaced with b_6 in that context. We could > just have easily recorded that b_6 can be replaced with i_1. > > I don't think we have any heuristics for which of those two equivalences to > record, it's strictly based on the order of appearance (which is likely > determined elsewhere by canonicalization rules). > > If you want to propose some heuristics, I'm all ears. One might be to put > the object with the least number of references on the lhs. THe idea would > be to try and ultimately get that use count to 0/1 which may allow that > object to die at the comparison. There may be some reasonable heuristic > around loop depth of the names as well. ie, do we want to replace uses of > a non-loop object with a loop object or vice versa? > > Anyway, open to suggestions here... The rule is simple - we should always replace with the more dominating definition because that's what value-numbering would do to be able to make the other defs unused.