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

Hello Duncan Sands, >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. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

Wojciech, I've just commited a patch to llvm-gcc 4.2, which moves openmp lowering stuff to be run little bit earlier, so llvm-convert will catch its result. It looks now gcc atomic & sync builtins should be introduced to llvm as a remaining ingredient. Example program from Diego's paper now compiles to: @.str = internal constant [10 x i8] c"sum = %d\0A\00" ;

I am not an optimizer guy, but, I am just thinking, if we can solve the problems that we are discussing in this mail chain, by introducing a middle-end in between front-end and LLVM. We may need to introduce GGC GIMPLE kind of IR (or any new suitable IR) in the middle-end so that front-end can produce this new IR, middle-end can consume it, and do all the parallelization and subsequent

Hello, I want to find out the member variable of the structure (.omp_data_i) being accessed but the metadata and the use don't seem to be linked. Here's is a portion of the IR generated for a function containing an OpenMP pragma: define internal void @bpnn_adjust_weights.omp_fn.0(i8* nocapture %.omp_data_i) nounwind uwtable { entry: %0 = getelementptr inbounds i8* %.omp_data_i, i64

Hi Dmitry, > > In our compiler we use a modified version LLVM Polly, which is very sensitive to > proper code generation. Among the number of limitations, the loop region > (enclosed by phi node on induction variable and branch) is required to be free > of additional memory-dependent branches. In other words, there must be no > conditional "br" instructions below phi

On 01/01/2013 02:45 PM, Duncan Sands wrote: > Hi Dmitry, > >> >> In our compiler we use a modified version LLVM Polly, which is very >> sensitive to >> proper code generation. Among the number of limitations, the loop region >> (enclosed by phi node on induction variable and branch) is required to >> be free >> of additional memory-dependent

Hi! I've been playing with gccgo / dragonegg, trying to get it to compile Go reliably. One of the problems I am currently facing is that when compiling Go, GCC tends to generate GIMPLE calls that don't have the correct type (or so it seems to me :) ). For instance, when compiling ddd.go from the Go testsuite, I get this: i.91 = i; D.785 = i.91.__methods; D.786 =

On Sat, Oct 13, 2012 at 2:33 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > On Sat, Oct 13, 2012 at 1:31 PM, Tobias Grosser <tobias at grosser.es> wrote: >> On 10/13/2012 04:38 AM, Mahesha HS wrote: >>> >>> On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> >>> wrote: >>>> >>>> On Wed, Oct 10,

I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`, so, `unit` must be present for `optimized ` too. Am I right? Mahesha On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote: > definition and optimized are orthogonal (a function could be both, or > neither) - one says this DISubprogram describes a function

Let's forget about my malformed IR if it is adding additional confusion here. I mentioned it here to ease the conversation, but if it is causing confusion rather than making the discussion flow easier, then we better ignore it. The whole triggering point for this email initiative is - one of the applications is crashing with the stack trace that I mentioned earlier. The crash is during the

Hi David If you look at line https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160 there is IR verification which asserts that only in case of `spFlags = DISPFlagDefinition`, the compilation unit (`unit` field) should be present. Otherwise, it should *not* be present. In the crash case, `spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be present,

Hi Duncan & Tobi, Thanks a lot for your interest, and for pointing out differences in GIMPLE I missed. Attached is simplified test case. Is it good? Tobi, regarding runtime alias analysis: in KernelGen we already do it along with runtime values substitution. For example: <------------------ __kernelgen_main_loop_17: compile started ---------------------> Integer args substituted:

Hi Eli, Attached zipped file, named, "fopenmp_option_support.tar.gz" contains the first patch, along with relevant *test case*. This patch is to support the option "-fopenmp" option in Clang. Following files are changed in this patch. Please start going through this patch, and let me know comments. Meanwhile, I will prepare next patch.

On 10/13/2012 04:38 AM, Mahesha HS wrote: > On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: >>> Hi Eli and Others >>> >>> In response to your feedback, I have taken care of all your review comments >>> - I removed clangOMP.a

Hi- Here is the simple C++ function: ----------- void foo() { } ----------- Let's say, above function is compiled to generate LLVM IR with -g flag using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get below IR ----------- ; ModuleID = 'foo.cpp' source_filename = "foo.cpp" target datalayout =

On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > Hi Eli and Others > > In response to your feedback, I have taken care of all your review comments > - I removed clangOMP.a > and moved the implementation of "class OmpPragmaHandler" to "clangLex.a". > > The attached zipped file - namely -

Dear all, In our compiler we use a modified version LLVM Polly, which is very sensitive to proper code generation. Among the number of limitations, the loop region (enclosed by phi node on induction variable and branch) is required to be free of additional memory-dependent branches. In other words, there must be no conditional "br" instructions below phi nodes. The problem we are facing

On Tue, 2 Oct 2012 14:28:25 +0000 "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

On Sat, Oct 13, 2012 at 1:31 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 10/13/2012 04:38 AM, Mahesha HS wrote: >> >> On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> >> wrote: >>> >>> On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> >>> wrote: >>>>

On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: >> Hi Eli and Others >> >> In response to your feedback, I have taken care of all your review comments >> - I removed clangOMP.a >> and moved the implementation of "class