On Tue, Nov 26, 2013 at 11:37 PM, Jeff Law <l...@redhat.com> wrote: > On 11/26/13 02:26, Richard Biener wrote: > >> But only necessary if this threading returned true, no? > > Correct. Fix for that spinning overnight. > > > >> Also >> how "likely" did it scramble the loop? I see that thread_block_1 >> already cancels loops in some cases so I wonder what case >> it misses so that you need to cancel the loop unconditonally here. > > If you get into that code, effectively always. We know we're threading > around the backedge through a multi-way branch at the top, then to some > interior node within the loop. It would depend on the precise structure of > the CFG within the loop, but basically if you get here, there is a good > chance you have irreducible loops. > > For a good example of how badly things can get scrambled, look at what we do > with 54742. Dump or draw CFGs before/after DOM1. It's painful to see what > we do to the loop structure, but removing that switch is such a huge win > that losing the loop structure has become a non-concern.
Ick ;) Loop fixup isn't able to recover the original loop here, it discovers a "new" one, the one just covering looping through the default: case of the switch. The first pass that allows CFG manipulations during loop init is able to disambiguate the mess DOM left us with and discovers a loop nest of depth 4. Nice transform I'd say ;) Richard. >> Do you have a testcase that ICEs if I remove the cancelling above? > > I'd have to review the PRs to recall if they were ICEs and/or codegen > failures. > > jeff >
