From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10745 invoked by alias); 13 Sep 2013 22:08:52 -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 10674 invoked by uid 48); 13 Sep 2013 22:08:47 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/55860] Turn segmented iteration into nested loops Date: Fri, 13 Sep 2013 22:08: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.8.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: 2013-09/txt/msg01037.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- My current work won't help this PR. edge equivalences are not well handled for threading. While the edge containing the equivalence for jlk < n dominates the true arm of the condition, it does not dominate the join point where the true/else arms meet. So it's not going to be available in the expression hash table when we try to thread the true arm. dom_opt_leave_block does some work to recover edge equivalences, but only for the edge from the block we're leaving to its successor blocks. The edge equivalence is higher up in the chain. In theory we could walk up the CFG and add more stuff to the tables, which would probably help. Assuming that worked, I still doubt threading is going to be successful as we have to thread through the backedge in the CFG and we're currently very conservative with that, both in terms of recording jump threads and in terms of which jump threads we'll ultimately realize. In this particular case, threading from the true arm through the backedge will create a new, inner loop which the threading code tries really hard not to do because it doesn't know how to update all the various loop structures. We have the same problem for the FSA optimization, but in that case I'm tempted to just throw away all the loop information -- if we thread a backedge and eliminate a switch, that's huge from a performance standpoint and we can probably afford to just throw away the loop info at that point.