------- 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
