similar to: [LLVMdev] Accessing structure members of .omp_data_i

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" ;

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

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

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

Hola a todos, en primer lugar quería agradecer la ayuda recibida desde el foro con respecto a la creación de una red neuronal. Estoy utilizando el paquete Neuralnet, que me parece que es bastante bueno, pero tengo el problema que soy incapaz de hacer las predicciones del modelo. Sé que se hace con el comando "compute", pero no encuentro ningún ejemplo de cómo hacerlo. ¿Alguien me puede

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)

Hi. I'm sending this email to -dev as this may be of interest of many/people may have opinions/want to try the change before it goes in to report problems. I've been recently working on a patch to integrate `undef` in the SCCP solver, in the hope of fixing a tail of latent bugs in SCCP which remained uncovered for many years. I think this is a decent time to propose, so that it can

On Fri, Dec 30, 2016 at 9:27 AM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi. > I'm sending this email to -dev as this may be of interest of > many/people may have opinions/want to try the change before it goes in > to report problems. > I've been recently working on a patch to integrate `undef` in the SCCP > solver, in the hope of fixing

Hi David, Looking at the original bug, it seems like a straightforward undef-propagation bug to me -- SCCP was folding "or undef, constant" to "undef", which is wrong. Why is changing that not the fix? That is, some variant of diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++

On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi David, > > Looking at the original bug, it seems like a straightforward > undef-propagation bug to me -- SCCP was folding "or undef, constant" > to "undef", which is wrong. Why is changing that not the fix? That > is, some variant of > You would still

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

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 >

Hi, On Fri, Dec 30, 2016 at 9:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi David, >> >> Looking at the original bug, it seems like a straightforward >> undef-propagation bug to me -- SCCP was folding "or undef, constant"

No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13

Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the

I see. And what's the purpose for outputting bitcode into *.o and *.a files? Do you want to perform an LLVM pass on linking step? 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hmm.. I didn't explain the problem completely last time. I am creating a > drop-in replacement for gcc and gfortran that runs an additional pass on the > bitcode before generating the native

On Wed, Mar 16, 2011 at 9:33 PM, Ashay Rane <ashay.rane at asu.edu> wrote: > Hi Eli, > Thanks for the reply. The problem is that getOperand() returns an > llvm::Instruction (that refers to the definition of the operand). What I am > trying to find out is how to get the value of the operand. When you refer to > bitcasting to i8*, do you mean casting the return value from

Thats correct. But using llc becomes a problem when I have archives (.a files). I could, in theory, extract its contents to a tempdir and then use llc and link but just wondering if there is a more elegant solution. Ashay On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Ashay, > > If I understand correctly, in hw.o you would have llvm