[LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)

[Andrey Bokhanko]

Vikram,

I agree with basically everything you said.

Yes, our (Intel) proposal is clearly OpenMP-specific. This is
obviously a deficiency that probably makes it unsuitable for inclusion
as a "first class" part of LLVM IR. What we intended is to have a
simple extension of LLVM IR (based on existing IR constructs) that
establishes common ground for front-end, back-end and runtime library
writers -- and thus, further progress of OpenMP support in LLVM
compiler toolchain.

Yours,
Andrey
---
Software Engineer
Intel Compiler Team
Intel Corp.

On Tue, Oct 2, 2012 at 6:28 PM, Adve, Vikram Sadanand
<vadve at illinois.edu> wrote:
> Hal, Andrey, Alexey,
>
> From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific.  OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics.  LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it.  I've included an excerpt from Hal's proposal below, which shows what I mean: the  design is couched in terms of OpenMP parallel regions.  Other parallel languages, e.g, Cilk, have no such notion.  The latest Intel proposal is at least as OpenMP-specific.
>
> I do agree with the general goal of trying to support parallel programming languages in a more first-class manner in LLVM than we do today.  But the right approach for that is to be as language-neutral as possible.  For example, any parallelism primitives in the LLVM IR and any LLVM- or machine-level optimizations that apply to parallel code should be applicable not only to OpenMP but also to languages like Cilk, Java/C#, and several others.  I think "libraries" like Intel's TBB should be supported, too: they have a (reasonably) well-defined semantics, just like languages do, and are become widely used.
>
> I also do not think LLVM metadata is the way to represent the primitives, because they are simply too fragile.   But you don't have to argue that one with me :-), others have argued this already.  You really need more first class, language-neutral, LLVM mechanisms for parallelism.  I'm not pretending I know how to do this, though there are papers on the subject, including one from an Intel team (Pillar: A Parallel Implementation Language, LCPC 2007).
>
> --Vikram
> Professor, Computer Science
> University of Illinois at Urbana-Champaign
> http://llvm.org/~vadve
>
>
>
>
>> To mark this function as a parallel region, a module-level 'parallel'
>> metadata entry is created. The call site(s) of this function are marked
>> with this metadata,. The metadata has entries:
>>  - The string "region"
>>  - A reference to the parallel-region function
>>  - If applicable, a list of metadata references specifying
>> special-handling child regions (parallel loops and serialized/critical
>> regions)
>>
>> If the special-handling region metadata is no longer referenced by code
>> within the parallel region, then the region has become invalid, and
>> will be removed (meaning all parallelization metadata will be removed)
>> by the ParallelizationCleanup. The same is true for all other
>> cross-referenced metadata below.
>>
>> Note that parallel regions can be nested.
>>
>> As a quick example, something like:
>> int main() {
>>   int a;
>> #pragma omp parallel firstprivate(a)
>>   do_something(a)
>>   ...
>> }
>>
>> becomes something like:
>>
>> define private void @parreg(i32 %a) {
>> entry:
>>   call void @do_something(i32 %a)
>>   ret
>> }
>>
>> define i32 @main() {
>> entry:
>> ...
>> call void @parreg1(i32 %a) !parallel !0
>> ...
>>
>> !0 = metadata !{ metadata !"region", @parreg }
>>
>
>
> --Vikram
> Professor, Computer Science
> University of Illinois at Urbana-Champaign
> http://llvm.org/~vadve
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev