<div class="gmail_quote"><div>Hello Duncan Sands,</div><div><br></div><div>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.</div>

<div><br></div><div>Now, it throws up following questions.</div><div><br></div><div><ol><li>Am I correct that DragoEgg should logically supports all the OMP benchmarks as supported by GCC (4.5 or later)?</li>
<li>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?  </li>

<li>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.</li>

</ol>It would be great, if you throw some light upon it.</div><div><br></div><div>-mahesh</div><div class="HOEnZb"><div class="h5"><div><br></div><br><div class="gmail_quote">On Fri, Jul 13, 2012 at 8:54 AM, Mahesha S <span dir="ltr"><<a href="mailto:mahesha.llvm@gmail.com" target="_blank">mahesha.llvm@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hello Duncan Sands,</div><div><br></div><div>From your reply, what I can understand is that there is no any new OPENMP specific instructions </div>

<div><div><br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 7:48 PM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mahesha,<br>
<div><div>> I am trying to understand the process followed for converting GIMPLE IR to LLVM<br>
> IR in LLVM-GCC/DragonEgg - more importantly conversion of OpenMP extended GIMPLE<br>
> IR to LLVM IR. It would be great if anybody points me to some documentation<br>
> before I my-self delve into the understanding of related source code.<br>
<br>
</div></div>dragonegg doesn't have to do anything special for openmp, since gcc has already<br>
lowered it to a bunch of extra functions and library calls by that point.<br>
<br>
Ciao, Duncan.<br>
<br>
PS: Here's an example:<br>
<br>
void foo()<br>
{<br>
   int i;<br>
<br>
   #pragma omp parallel<br>
     {<br>
     #pragma omp parallel<br>
       {<br>
       #pragma omp parallel<br>
         {<br>
           i++;<br>
         }<br>
       }<br>
     }<br>
}<br>
<br>
-> (the LLVM IR is a direct transliteration of the gimple):<br>
<br>
target datalayout =<br>
"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"<br>
target triple = "x86_64-unknown-linux-gnu"<br>
<br>
module asm "\09.ident\09\22GCC: (GNU) 4.7.1 20120603 (prerelease) LLVM: 3.2svn\22"<br>
<br>
%struct..omp_data_s.2 = type { i32* }<br>
%struct..omp_data_s.1 = type { i32* }<br>
%struct..omp_data_s.0 = type { i32 }<br>
<br>
define internal void @foo._omp_fn.2(i8* nocapture %.omp_data_i) nounwind uwtable {<br>
entry:<br>
   %0 = bitcast i8* %.omp_data_i to i32**<br>
   %1 = load i32** %0, align 8<br>
   %2 = load i32* %1, align 4<br>
   %3 = add i32 %2, 1<br>
   store i32 %3, i32* %1, align 4<br>
   ret void<br>
}<br>
<br>
define internal void @foo._omp_fn.1(i8* nocapture %.omp_data_i) nounwind uwtable {<br>
entry:<br>
   %.omp_data_o.3 = alloca %struct..omp_data_s.2, align 8<br>
   %0 = bitcast i8* %.omp_data_i to i32**<br>
   %1 = load i32** %0, align 8<br>
   %2 = getelementptr inbounds %struct..omp_data_s.2* %.omp_data_o.3, i64 0, i32 0<br>
   store i32* %1, i32** %2, align 8<br>
   %3 = bitcast %struct..omp_data_s.2* %.omp_data_o.3 to i8*<br>
   call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.2, i8* %3, i32 0)<br>
nounwind<br>
   call void @foo._omp_fn.2(i8* %3) nounwind uwtable<br>
   call void @GOMP_parallel_end() nounwind<br>
   ret void<br>
}<br>
<br>
declare void @GOMP_parallel_start(void (i8*)*, i8*, i32) nounwind<br>
<br>
declare void @GOMP_parallel_end() nounwind<br>
<br>
define internal void @foo._omp_fn.0(i8* %.omp_data_i) nounwind uwtable {<br>
entry:<br>
   %.omp_data_o.4 = alloca %struct..omp_data_s.1, align 8<br>
   %0 = bitcast i8* %.omp_data_i to i32*<br>
   %1 = getelementptr inbounds %struct..omp_data_s.1* %.omp_data_o.4, i64 0, i32 0<br>
   store i32* %0, i32** %1, align 8<br>
   %2 = bitcast %struct..omp_data_s.1* %.omp_data_o.4 to i8*<br>
   call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.1, i8* %2, i32 0)<br>
nounwind<br>
   call void @foo._omp_fn.1(i8* %2) nounwind uwtable<br>
   call void @GOMP_parallel_end() nounwind<br>
   ret void<br>
}<br>
<br>
define void @foo(...) nounwind uwtable {<br>
entry:<br>
   %.omp_data_o.5 = alloca %struct..omp_data_s.0, align 8<br>
   %0 = bitcast %struct..omp_data_s.0* %.omp_data_o.5 to i8*<br>
   call void @GOMP_parallel_start(void (i8*)* @foo._omp_fn.0, i8* %0, i32 0)<br>
nounwind<br>
   call void @foo._omp_fn.0(i8* %0) nounwind uwtable<br>
   call void @GOMP_parallel_end() nounwind<br>
   ret void<br>
<div><div>}<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>Cheers<div>-mahesha</div><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Cheers<div>-mahesha</div><br>
</font></span></div><br><br clear="all"><div><br></div>-- <br>Cheers<div>-mahesha</div><br>