This is the mail archive of the
mailing list for the GCC project.
Re: [gomp4] Compiler side of the cancellation support
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 09 Jul 2013 10:12:30 -0700
- Subject: Re: [gomp4] Compiler side of the cancellation support
- References: <20130703103929 dot GM2336 at tucnak dot redhat dot com>
On 07/03/2013 03:39 AM, Jakub Jelinek wrote:
> This is the compiler side of the #pragma omp cancel and #pragma omp
> cancellation point support. On the library side what is needed is:
> 1) GOMP_cancellation_point now returns a bool (whether the relevant
> cancellation was observed)
> 2) GOMP_cancel now has two arguments instead of just one, and returns
> bool like GOMP_cancellation_point. If the second argument is false,
> it acts just like GOMP_cancellation_point, if it is true, it cancels
> the given construct. For both these calls the first argument is
> 1 for parallel cancellation, 2 for loop cancellation, 4 for sections and
> 8 for taskgroup cancellation.
> 3) GOMP_barrier_cancel which is like GOMP_barrier, but should check
> for pending parallel cancellation and if parallel is cancelled, should
> return true
> 4) GOMP_sections_end_cancel and GOMP_loop_end_cancel variants to the
> non-cancel libcalls for the cancellation checking implicit barriers
> The still unsolved problems are that for firstprivate/lastprivate
> for, copyin_ref we add an implicit barrier that isn't really in the standard
> and similarly for #pragma omp single copyprivate we don't use one barrier
> mandated by the standard, but actually two barriers. Not sure what exactly
> we want as the behavior for these. As some subset of threads can be
> canceled before reaching the unofficial barrier (say one with #pragma omp
> cancel parallel before reaching the omp for or omp single copyprivate)
> and some others with #pragma omp cancellation point parallel, while some
> threads hit the unofficial barrier before the cancellation (and optionally
> some afterwards), do we want in the library to just arrange for all barriers
> to be awaken and not block until the final barrier at the end of parallel is
> hit, and for the unofficial barriers just not to return anything, while
> for the official barriers (*_cancel suffixed) return true to signal jump to
> end of region with running dtors?
> Or perhaps keep track on how many threads in parallel have already observed
> the cancellation and wait on non-*_cancel barriers only for the rest of the
> threads that haven't observed it yet, and only on the *_cancel barriers
> observe it for all threads.
> Another issue is what if the dtors executed on the way contain barriers,
> but that is probably ruled out by the restriction that
> "A construct that may be subject to cancellation must not encounter an orphaned
> cancellation point."
> Queuing this patch until we have a library implementation.
I've committed the patch, so that I can more easily work on the library
implementation. There was one minor patch conflict that needed resolving.