[LLVMdev] Fwd: Documentation about converting GIMPLE IR to LLVM IR in LLVM-GCC/DragonEgg

Duncan Sands baldrick at free.fr
Thu Jul 12 23:24:52 PDT 2012


Hi Mahesha,
>  From your reply, what I can understand is that there is no any new OPENMP
> specific instructions introduced into LLVM IR as a part of DragonEgg project
> since GCC has already done the job of lowering OpenMP directives into GOMP
> runtime library calls at LOW GIMPLE IR level.

correct.

> Now, it throws up following questions.
>
>  1. Am I correct that DragoEgg should logically supports all the OMP benchmarks
>     as supported by GCC (4.5 or later)?

Yes.

>  2. If we decide to support OpenMP directly in LLVM what is the better way to
>     handle it? Suppose, assume that we decide to support OpenMP through Clang.
>     Then, do you think that Clang should also follow the same mechanism as
>     DragoEgg does by lowering all the OpenMP directives into OMP runtime library
>     calls so that it is not necessary to add any extra new OpenMP related
>     instructions into LLVM IR?

Personally I think openmp lowering should (mostly) be done in clang, at least to
begin with.  Maybe over time some openmp constructs or helper IR manipulation
routines could be added to LLVM.

>  3. Assume that tomorrow, some other front-end other than GCC/Clang is being
>     plugged into LLVM back-end. Or assume that sometime later new FROTRAN
>     front-end is being introduced along with Clang. Or Someone wants to plug-in
>     EDG front-end into LVVM back-end. Or OpenACC needs to be supported in LLVM.
>     Or OpenACC may get merge with OpenMP and becomes of one of the standard
>     platforms to program heterogeneous architectures. By considering all these
>     and other future possibilities, what is the best way to support OpenMP in
>     LLVM. By best, I mean here that LLVM should not compromise with any other
>     compilers in terms of OpenMP features completeness, bench mark results, and
>     the OpenMP infrastructure laid out in LLVM should be flexible enough to
>     handle above mentioned future possibilities.

LLVM IR is not a universal internal language representation.  It is a mistake
to try to add everything and the kitchen sink to it (eg: openmp pragmas) just
because many languages/front-ends may support openmp, in my opinion.

Ciao, Duncan.

>
> It would be great, if you throw some light upon it.
>
> -mahesh
>
>
> On Fri, Jul 13, 2012 at 8:54 AM, Mahesha S <mahesha.llvm at gmail.com
> <mailto:mahesha.llvm at gmail.com>> wrote:
>
>     Hello Duncan Sands,
>
>      From your reply, what I can understand is that there is no any new OPENMP
>     specific instructions
>
>
>     On Thu, Jul 12, 2012 at 7:48 PM, Duncan Sands <baldrick at free.fr
>     <mailto:baldrick at free.fr>> wrote:
>
>         Hi Mahesha,
>          > I am trying to understand the process followed for converting GIMPLE
>         IR to LLVM
>          > IR in LLVM-GCC/DragonEgg - more importantly conversion of OpenMP
>         extended GIMPLE
>          > IR to LLVM IR. It would be great if anybody points me to some
>         documentation
>          > before I my-self delve into the understanding of related source code.
>
>         dragonegg doesn't have to do anything special for openmp, since gcc has
>         already
>         lowered it to a bunch of extra functions and library calls by that point.
>
>         Ciao, Duncan.
>
>         PS: Here's an example:
>
>         void foo()
>         {
>             int i;
>
>             #pragma omp parallel
>               {
>               #pragma omp parallel
>                 {
>                 #pragma omp parallel
>                   {
>                     i++;
>                   }
>                 }
>               }
>         }
>
>         -> (the LLVM IR is a direct transliteration of the gimple):
>
>         target datalayout =
>         "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
>         target triple = "x86_64-unknown-linux-gnu"
>
>         module asm "\09.ident\09\22GCC: (GNU) 4.7.1 20120603 (prerelease) LLVM:
>         3.2svn\22"
>
>         %struct..omp_data_s.2 = type { i32* }
>         %struct..omp_data_s.1 = type { i32* }
>         %struct..omp_data_s.0 = type { i32 }
>
>         define internal void @foo._omp_fn.2(i8* nocapture %.omp_data_i) nounwind
>         uwtable {
>         entry:
>             %0 = bitcast i8* %.omp_data_i to i32**
>             %1 = load i32** %0, align 8
>             %2 = load i32* %1, align 4
>             %3 = add i32 %2, 1
>             store i32 %3, i32* %1, align 4
>             ret void
>         }
>
>         define internal void @foo._omp_fn.1(i8* nocapture %.omp_data_i) nounwind
>         uwtable {
>         entry:
>             %.omp_data_o.3 = alloca %struct..omp_data_s.2, align 8
>             %0 = bitcast i8* %.omp_data_i to i32**
>             %1 = load i32** %0, align 8
>             %2 = getelementptr inbounds %struct..omp_data_s.2* %.omp_data_o.3,
>         i64 0, i32 0
>             store i32* %1, i32** %2, align 8
>             %3 = bitcast %struct..omp_data_s.2* %.omp_data_o.3 to i8*
>             call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.2, i8* %3,
>         i32 0)
>         nounwind
>             call void @foo._omp_fn.2(i8* %3) nounwind uwtable
>             call void @GOMP_parallel_end() nounwind
>             ret void
>         }
>
>         declare void @GOMP_parallel_start(void (i8*)*, i8*, i32) nounwind
>
>         declare void @GOMP_parallel_end() nounwind
>
>         define internal void @foo._omp_fn.0(i8* %.omp_data_i) nounwind uwtable {
>         entry:
>             %.omp_data_o.4 = alloca %struct..omp_data_s.1, align 8
>             %0 = bitcast i8* %.omp_data_i to i32*
>             %1 = getelementptr inbounds %struct..omp_data_s.1* %.omp_data_o.4,
>         i64 0, i32 0
>             store i32* %0, i32** %1, align 8
>             %2 = bitcast %struct..omp_data_s.1* %.omp_data_o.4 to i8*
>             call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.1, i8* %2,
>         i32 0)
>         nounwind
>             call void @foo._omp_fn.1(i8* %2) nounwind uwtable
>             call void @GOMP_parallel_end() nounwind
>             ret void
>         }
>
>         define void @foo(...) nounwind uwtable {
>         entry:
>             %.omp_data_o.5 = alloca %struct..omp_data_s.0, align 8
>             %0 = bitcast %struct..omp_data_s.0* %.omp_data_o.5 to i8*
>             call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.0, i8* %0,
>         i32 0)
>         nounwind
>             call void @foo._omp_fn.0(i8* %0) nounwind uwtable
>             call void @GOMP_parallel_end() nounwind
>             ret void
>         }
>         _______________________________________________
>         LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>     --
>     Cheers
>     -mahesha
>
>
>
>
> --
> Cheers
> -mahesha
>
>
>
>
> --
> Cheers
> -mahesha
>





More information about the llvm-dev mailing list