From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8215 invoked by alias); 7 Feb 2006 21:24:46 -0000 Received: (qmail 8144 invoked by uid 48); 7 Feb 2006 21:24:43 -0000 Date: Tue, 07 Feb 2006 21:24:00 -0000 Message-ID: <20060207212443.8143.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/21417] Missed jump threading opportunity on trees In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "law at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-02/txt/msg00704.txt.bz2 List-Id: ------- Comment #4 from law at redhat dot com 2006-02-07 21:24 ------- The jump threading code is *very* conservative when threading across a backedge in the CFG. The fundamental issue is that you'll have the result of the conditional in your hash tables from the normal DOM walk and you may (incorrectly) use that result. ie, think about the case where you've got something like this at the head of a loop x = y->z if (x == 42) ... If you traverse a backedge to that block and try to thread through the block, you can get incorrect results since you'll have recorded knowledge about x in your hash tables already, but x's value may change from one iteration to the next. Threading the backedge *is* safe when statements in the target block do not affect the result of the conditional at the end of the target block. I found that handling the trivial case (there are *no* statements other than the conditional) caught most of the cases of threadable backedges I had encountered. It shouldn't be terribly hard to look at the operands of the conditional and allow threading a backedge if the operands of the conditional are not set in statements in the same block as the conditional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417