From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16323 invoked by alias); 16 Feb 2015 19:05:31 -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 16279 invoked by uid 48); 16 Feb 2015 19:05:27 -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: Mon, 16 Feb 2015 19:05: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: 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/msg01821.txt.bz2 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. Dominance doesn't seem to be the right thing to be looking at to me since the crux of this issue is propagating the "copy" implied by the equality comparison just changes what SSA_NAME we reference and as a result ultimately hides stuff from later passes. It doesn't (in this case) enable further simplifications or for either SSA_NAME to become unused. A dominance test between the args of the equality comparison just doesn't seem helpful here. In fact, because both names are used in the equality test, these propagations can never cause an SSA_NAME to become unused. At best the propagation will expose some further simplification on one of the paths or it will result in one SSA_NAME having a single use (the comparison). We have no good way of guessing if the former will happen, but we can encourage the latter. But as I mentioned earlier, I really wonder if we should allow these context sensitive equivalences to be expressed in the gimple if they didn't prove useful. And that was the whole purpose behind uncprop -- to find context sensitive propagations that ultimately didn't prove useful and which result in poor coalescing or unwanted constant initializations and un propagate them. It wouldn't directly help this problem because the use is in a normal statement, but it's definitely closely related and it wouldn't be hard to repurpose that code. In fact, it might be a good thing to do in general. Essentially what it's doing is building a map of values back to SSA_NAMEs which hold those values by way of an equality comparison. At each use of the value, we can look at the list of SSA_NAMEs that hold that value and select the one that appears to be least cost based on whatever metrics we see fit.