On 07/03/2013 03:39 AM, Jakub Jelinek wrote: > Hi! > > 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. r~
