Hi, > On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote: > > I agree -- at the very least, unswitch_single_loop should check whether > > there > > is any possiblity it could have affected irreducible loops information (this > > should only be the case when some already existing irreducible loop is > > altered > > in the progress). Which is what it (or more precisely, remove_path function > > used by it) tries to do -- so is should be sufficient to check why this > > fails > > for the considered testcase, and make sure the situation is correctly > > detected, > > Actually, in this case, we don't call remove_path from unswitch_single_loop > at all.
I am not quite sure what you mean by that -- remove_path is called unconditionally in unswitch_loop (and fix_loop_placement is only called through remove_path). > So, here's another stab at it. In this version, we will call > mark_irreducible_loops only in case where we're removing a loop > from loop hierarchy tree. Because when we do that (and we're in some > irreducible region), the edge that connects those two loops > should be marked as EDGE_IRREDUCIBLE_LOOP. And the preheader BB > eventually as BB_IRREDUCIBLE_LOOP. Does this look any better? > I'm not actually checking whether we really are in a irreducible > region, should that be done (how?)? Yes, you should check whether you are in an irreducible loop. This is done by testing EDGE_IRREDUCIBLE_LOOP flag, Zdenek
