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