[LLVMdev] OpenMP support for LLVM

[Hal Finkel]

On Wed, 18 Jan 2012 15:45:09 +0530
Sanjoy Das <sanjoy at playingwithpointers.com> wrote:

> Hi all,
> 
> I'd like to put in some effort into this too -- perhaps I can write an
> backend for libgomp while someone else works on a libmpc one.
> 
> As far as the architecture is concerned, I concur with what has
> already been discussed: mapping OpenMP constructs to LLVM intrinsics.
> I think it would make sense to leave out intrinsics for things like
> "parallel for", "parallel sections", which are essentially syntactic
> sugar.

I agree.

> 
> One way to denote a structured block could be by nesting it within two
> intrinsics like

I am not sure how well this will work in practice, but we should come
up with a plan. As far as I can tell, we have two options: intrinsics
and metadata; we may want to use some combination of the two. One key
issue is to decide how optimization passes will interact with the
parallelization constructs. I think that it is particularly important
that using OpenMP does not preclude loop unrolling and LICM, for
example.

As you mention, we'll also want to provide the ability to do
target-specific lowering of certain constructs (like atomics). We also
want to make sure that we can recognize and optimize expressions that
are constant for a given thread within a parallel region (like a
get-thread-id operation).

Thoughts?

 -Hal

> 
> llvm.openmp.parallel_begin (llvm.openmp.clause_if(%1) <and so forth>)
>   body
> llvm.openmp.parallel_end()
> 
> or we could pass in an end label to parallel_begin (we can then call
> it parallel instead of parallel_begin).  I'm not sure which one is the
> better idea.  There will have to be restrictions on the body, of
> course.  We can't allow control to jump outside body without
> encountering the barrier, for instance.
> 
> The more difficult problem would be, I think, to lift the structured
> block and create a function out of it that takes a closure.
> 
> I also think there is potential for optimizing things like the
> reduction clause and the atomic construct by lowering them directly
> into CAS or other machine instructions.  But I'll stop here before I
> get ahead of myself. :)
> 
> Thanks!



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory