From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30179 invoked by alias); 17 Feb 2015 15:40:06 -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 30077 invoked by uid 55); 17 Feb 2015 15:40:02 -0000 From: "law at redhat dot com" 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: Tue, 17 Feb 2015 15:40: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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com 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/msg01907.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 --- Comment #13 from Jeffrey A. Law --- On 02/17/15 02:44, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 > > --- Comment #10 from rguenther at suse dot de --- > On Mon, 16 Feb 2015, law at redhat dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 >> >> --- Comment #9 from Jeffrey A. Law --- Yes, any >> particular choice has the potential to regress in one way or another. >> These are heuristics after all. We're just looking for a reasonable >> refinement if we can find one. > > Well, there is also canonicalization for CSE / jump threading. Consider > > if (i == 2) > { > if (i != j) > ... > else if (j == 2) > ... > > or > > y = 2 * i; > if (i == j) > x = i + j; > > but yes, this is followup transforms. Unfortunately(?) DOM performs > copy/constant propagation for all recorded equalities. Yea, I've been mulling what it would take to instead build equivalence classes, then when we find a use walk through the class and see which one is "best". I suspect the vast majority of the time the "best" is always going to be the same -- the major exception will be these temporary equivalences. I've also been pondering somehow marking the equivalent values with some kind of tag indicating their scope and using that to guide propagation. But I haven't prototyped anything... > > As you say, we don't know - we only know that properly canonicalizing > will expose the followup transforms if there are any. It looks like > we are basically taking the original order of EQ_EXPR operands > (thus eventually rely on tree_swap_operands canonicalization) plus > the "correctness" thing of taking into account loop depth (which is > kind of a dominance relation). Correct, we take it from the original order and thus from the earlier canonicalization via tree_swap_operands. > > We are also introducing SSA_NAME_VALUE "chains" in record_equality > as we are setting x SSA_NAME_VALUE to y not to SSA_NAME_VALUE (y) > (we seem to do this in multiple places for some odd reason..., > only tree-ssa-threadedge.c:record_temporary_equivalence seems to get > this right). Even if we set to SSA_NAME_VALUE (y) we can end up with chains. But this change might eliminate the benefit of the chain walk, which would be good. Jeff