similar to: [LLVMdev] LLVM and OpenMP

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

Dear All, 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. -- Cheers -mahesha -------------- next part -------------- An HTML attachment

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, I was wondering whether or not MPI-libraries are expected to work with llvm-gcc? I tried to compile openmpi-1.3 using the llvm-gcc4.2-2.5-x86-darwin9 distribution on my MacBook Pro running OS 10.5.6. Installation using the gcc (gcc version 4.0.1 (Apple Inc. build 5490)) worked well. But for the llvm-gcc I get the following error message (during the make): > .... > Making all

I'm curious why I am seeing this: *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum %scevgep1920 = bitcast i8* %scevgep19 to i16* %tmp78 = load i16* %scevgep1920, align 2 * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum %scevgep1516 = bitcast i8* %scevgep15 to i16*

On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45

On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45

That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM,

Eli, Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. behavior? It seems to me that codegenprepare is doing a useful thing (for me, since I'm just using the llvm IR and not going to backend, providing it's "exposing" and not simply "adding for layout for CodeGen opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44

Ok, thanks. Even still though I would expect -instcombine (run after lsr) would do this cleanup? On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > That solves the issue but it seems odd to me that instcombine doesn't take > care of it? > > > LSR is

On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That solves the issue but it seems odd to me that instcombine doesn't take care of it? LSR is part of the backend. It's lowering the IR for a specific target. It seems to think those redundant operations are good for reducing register pressure, but doesn't actually have much knowledge about register

On Oct 19, 2012, at 2:44 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks. > > Even still though I would expect -instcombine (run after lsr) would do this cleanup? It's valid to run any IR pass after -loop-reduce. So you can try it. -gvn is probably what you're looking for. It isn't something we normally want to do. Turn off LSR if it does bad things on

Hello, I have been facing a few problems getting names of variables from the bitcode. The bitcode does contain debug metadata. The first problem is regarding `memtmp' variables (apparently, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence establishing a connection to the debug metadata

On Feb 29, 2012, at 2:59 PM, Ashay Rane wrote: > I have been facing a few problems getting names of variables from the bitcode. The bitcode does contain debug metadata. The first problem is regarding `memtmp' variables (apparently, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence

Yes I think I can. The original compile line was: llvm-g++ -DHAVE_CONFIG_H -I. -I../.. -I../../extlib/otf/otflib -I../../ extlib/otf/otflib -I../../vtlib/ -I../../vtlib -D_REENTRANT -fopenmp - DVT_OMP -O2 -MT vtfilter-vt_tracefilter.o -MD -MP -MF .deps/vtfilter- vt_tracefilter.Tpo -c -o vtfilter-vt_tracefilter.o `test -f 'vt_tracefilter.cc' || echo './'`vt_tracefilter.cc I

The following code using OpenMP pragmas , when compiled with gcc 4.5 + LLVM 2.8 + DragonEgg 2.8 and ran, produces segmentation fault. //----------------------------------------------------------- #define LOOPCOUNT 10000 int main() { int bit_and = 1; int logics[LOOPCOUNT]; int i; for (i = 0; i < LOOPCOUNT; ++i) { logics[i] = 1; } #pragma omp parallel for schedule(dynamic,1)

Eli, Actually, I stil see this issue without codegenprepare being used. I'm also compiling with -o3. So I'm still not sure why I'm seeing this issue? Thanks. On Wed, Oct 17, 2012 at 1:54 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > > Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. > behavior? > > It seems to me

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

Thanks, I thought about clang but I need to work with Fortran programs too. Hence using dragonegg. Ashay On Wed, Feb 29, 2012 at 4:08 PM, Xi Wang <xi.wang at gmail.com> wrote: > On Feb 29, 2012, at 2:59 PM, Ashay Rane wrote: > > I have been facing a few problems getting names of variables from the > bitcode. The bitcode does contain debug metadata. The first problem is >