John, it is for compatibility. We have to use kmp_cancel_barrier()
(we're going to implement full OpenMP 4.0), but there can be some old
solutions that can use old _kmpc_barrier() function.
Actually, I was mistaken when implemented 'omp barrier' using legacy
kmpc_barrier() instead of the new one kmpc_cancel_barrier() and this
patch just fixes it.
Best regards,
Alexey Bataev
=============
Software Engineer
Intel Compiler Team
03.12.2014 23:12, John McCall пишет:
================
Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:640
@@ -642,3 +639,3 @@
OpenMPLocationFlags Flags) {
- // Build call __kmpc_barrier(loc, thread_id)
+ // Build call __kmpc_cancel_barrier(loc, thread_id);
llvm::Value *Args[] = {EmitOpenMPUpdateLocation(CGF, Loc, Flags),
----------------
ABataev wrote:
rjmccall wrote:
Does this runtime function always exist, or is it contingent on having a
sufficiently new OpenMP runtime? If the latter, you should introduce the
concept of a target OpenMP runtime version, patterned on the target Objective-C
runtime version.
Also, please describe in a comment why we're using this function rather than the other,
since apparently both "work" in some sense.
Yes, it exists always. In OpenMP 3.1 it works just the same way as a regular
kmpc_barrier() (actually, kmpc_cancel_barrier just calls it). But it adds
processing of cancellation directives introduced in OpenMP 4.0.
Ok, I'll add the comment.
Okay. Is that desired for the existing uses of EmitOMPBarrierCall? If
everybody always wants a cancel barrier, and both runtime functions take the
same arguments, why are there two runtime functions at all?
http://reviews.llvm.org/D6447
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
