[PATCH] [OPENMP] Codegen for 'omp barrier' directive.

[Bataev, Alexey]

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