This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Improve handling of threads which cross over the current loops header
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 26 Nov 2013 15:37:57 -0700
- Subject: Re: [PATCH] Improve handling of threads which cross over the current loops header
- Authentication-results: sourceware.org; auth=none
- References: <528F0C4E dot 5050902 at redhat dot com> <CAFiYyc0FnL0nosr=5ZJKqt4pTVn+B=bC8hw-Q=f+R+1KS5RXiQ at mail dot gmail dot com> <528F7CBF dot 5010109 at redhat dot com> <627de6aa-c058-4443-8399-d1f1cc3c3cbb at email dot android dot com> <52939600 dot 4060802 at redhat dot com> <CAFiYyc0s2ydnSXP0mO6F3MjCHBvao77=HCcbY4fj4KfocER4rA at mail dot gmail dot com>
On 11/26/13 02:26, Richard Biener wrote:
But only necessary if this threading returned true, no?
Correct. Fix for that spinning overnight.
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.
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.
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.
I'd have to review the PRs to recall if they were ICEs and/or codegen
Do you have a testcase that ICEs if I remove the cancelling above?