Devang,> The easiest route would be to update llvm bitcode converter in llvm- > gcc-4.2 such that llvm bitcode converter operates on GCC trees after > OpenMP lowering phase is executed. > > If you're interested, we welcome contribution on OpenMP front.I already slightly looked on OpenMP in llvm-gcc 4.2. Internally OpenMP lowering in gcc is split into two phases. Funny, but llvm converter is run between these phases :) It looks like second phase uses some gcc analysis passes (like dominance info, etc). In order to support OpenMP in llvm-gcc 4.2 we should: 1. Decide at which level we should handle openmp trees in llvm-gcc 2. Define a set of openmp builtins, which will need to be supported in llc codegen 3. Something I'm not aware of :) If anyone want to work on bringing openmp to llvm-gcc, I'll be happy to help. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Hi, In the beginning I'd like to say I am not very familiar with (llvm-)gcc internals, so some of my assumptions and guesses may be wrong. Please, correct me, then. Anton Korobeynikov wrote:> Internally OpenMP lowering in gcc is split into two phases. Funny, but > llvm converter is run between these phases :) It looks like second phase > uses some gcc analysis passes (like dominance info, etc). > > In order to support OpenMP in llvm-gcc 4.2 we should: > 1. Decide at which level we should handle openmp trees in llvm-gcc > 2. Define a set of openmp builtins, which will need to be supported in > llc codegen > 3. Something I'm not aware of :)I've found an interesting paper on the design and implementation of OpenMP in GCC: http://people.restadhat.com/dnovillo/Papers/gcc2006.pdf It describes how and when OpenMP pragmas are lowered. It seems the second phase that Anton wrote about is the most important one. I believe it is the "pass_expand_omp" mentioned in the paper. Its aim is to extract parallel sections into new functions, expand directives into built-in function calls, insert code to calculate iteration-space, etc. I guess no GIMPLE codes used by OpenMP are left after this pass. If it is possible to do the conversion to LLVM IR at this stage, the only thing to do is to handle OpenMP built-ins. The simplest route would be to replace them with calls to libgomp (an LGPL library accompanying GCC). It is what GCC seems to do. The second option is allowing to somehow express OpenMP directives directly in the LLVM (or some general multiprocessing directives that OpenMP ones can be lowered to). Then, a pass could be written that handles them in a similar fashion to "pass_expand_omp" in GCC (see above). Any frontend (i.e. clang) would have simpler job supporting OpenMP then. That said, I admit I have no idea how to express these directives. For example: how to annotate a loop that it should be turned into a parallel one? I believe keeping the IR as simple as possible is an important goal, so we would need some lightweight mechanism, transparent to the existing passes. I'm personally interested in the subject, because I am trying to develop an automatic loop parallelization pass for LLVM. Initially, I thought I would write anything from scratch. However, if there is a decision to include some support for OpenMP (and similar techniques) lowering in the LLVM core, I'am ready to help. --Wojtek
On Nov 29, 2007, at 9:52 AM, Wojciech Matyjewicz wrote:> Hi, > > In the beginning I'd like to say I am not very familiar with > (llvm-)gcc > internals, so some of my assumptions and guesses may be wrong. Please, > correct me, then. > > Anton Korobeynikov wrote: >> Internally OpenMP lowering in gcc is split into two phases. Funny, >> but >> llvm converter is run between these phases :) It looks like second >> phase >> uses some gcc analysis passes (like dominance info, etc). >> >> In order to support OpenMP in llvm-gcc 4.2 we should: >> 1. Decide at which level we should handle openmp trees in llvm-gcc >> 2. Define a set of openmp builtins, which will need to be supported >> in >> llc codegen >> 3. Something I'm not aware of :) > > I've found an interesting paper on the design and implementation of > OpenMP in GCC: http://people.restadhat.com/dnovillo/Papers/gcc2006.pdf > It describes how and when OpenMP pragmas are lowered. It seems the > second phase that Anton wrote about is the most important one. I > believe > it is the "pass_expand_omp" mentioned in the paper. Its aim is to > extract parallel sections into new functions, expand directives into > built-in function calls, insert code to calculate iteration-space, > etc. > I guess no GIMPLE codes used by OpenMP are left after this pass. If it > is possible to do the conversion to LLVM IR at this stage, the only > thing to do is to handle OpenMP built-ins. The simplest route would be > to replace them with calls to libgomp (an LGPL library accompanying > GCC). It is what GCC seems to do.This is what I referred to. - Devang
On Nov 29, 2007, at 9:52 AM, Wojciech Matyjewicz wrote:> The simplest route would be > to replace them with calls to libgomp (an LGPL library accompanying > GCC). It is what GCC seems to do.Actually gcc expands things _and_ makes calls into libgomp so lowering omp first would be the best - otherwise you'll need to handle the language structures. -eric