similar to: [LLVMdev] adding a new pragma in OpenMP

I am trying to parallelize part of a C function that is called from R (via .C) using OpenMP's "parallel for" pragma. I get mixed results: some runs finish with no problem, but some lead to R crashing after issuing a long error message involving memory violations. I found this post, which describes how a .Call() function can be made to avoid crashing R by raising the stack limit:

Hi all, I am new to llvm. Does llvm has support for openmp directives like #pragma openmp threadprivate(var)? If so does the variable 'var' can be class objects instead of Plain Old Datatypes (POD) like int, float etc. g++ allows the #pragma openmp threadprivate(var) primitive only for the POD type. Please check the bug link at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 . Please

Hi Karthik, > I am new to llvm. Does llvm has support for openmp directives like #pragma > openmp threadprivate(var)? LLVM has no special support for openmp. The LLVM front-ends that support openmp, namely llvm-gcc and dragonegg, lower openmp constructs down to library calls the same way GCC does. This is no coincidence: both of those front-ends are based on GCC and just let the GCC

Hi Reid, Thank you for your response. In my analysis, I will always have entry(2) and exit(2). I will not run into cases involving entry (1+1) or entry (fn return values). I am having trouble trying to compare the arguments of entry and exit in the following scenario. #include<stdio.h> #include<stdlib.h> #include<pthread.h> struct sa { int a; pthread_mutex_t *mutex1;

On 07/04/2012 10:35 AM, Raghavendra, Prakash wrote: > Hi > > I wanted to know the status of OpenMP (or in general auto > parallelization) support in > > LLVM. > > I read some threads discussing about possible effort in that direction > in 3.1 onwards, > > but did not see any further discussion on that. > > If someone in the list knows the updated info or can

Could you be more precise about what you mean by "identical"? Would entry(2) and entry(1+1) be considered equivalent? If the same Value* is passed to entry and exit, then pointer equality (==) will detect that. Reid On Mon, Mar 7, 2011 at 8:08 AM, Hari Pyla <harip at vt.edu> wrote: > Hi, >  I am trying to identify if two functions were called with exactly the same

On Wed, Oct 10, 2012 at 5:40 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Tue, Oct 9, 2012 at 4:37 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > > Hello All, > > > > We would like to make a proposal to support OpenMP in CLANG. The goal of > > this effort is to provide support for syntax > > > > analysis (parsing), semantic

If I understand correctly, you're saying that the C source definition of the prologue function is declared as static. If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name. As such, it will never get inlined as the instrumented code

If LLVM would like to support OpenMP pragma in the future, not sure if attaching metadata to instructions is still a good choice. Junjie On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges

Hi, I am trying to identify if two functions were called with exactly the same argument. For instance, in the below example, assuming both entry() and exit() functions take a single argument, I would like to know if arg1 in entry() is same as arg1in exit(). int a; struct sa { int b; int c; }; int main () { struct sa s; entry (arg1); ... exit (arg1); return 0; } In

Hi Francesco, This is a huge RFC and I don't think we can discuss all of it at the same time, at least not in a constructive manner. What ends up happening is that people ignore the thread and developers get upset. So, I'll start with the summary, to make sure the overall assumptions in the RFC match the ones I have about it, then we can delve into details. I also think we should not

Hi I wanted to know the status of OpenMP (or in general auto parallelization) support in LLVM. I read some threads discussing about possible effort in that direction in 3.1 onwards, but did not see any further discussion on that. If someone in the list knows the updated info or can point me to any useful info, that would be useful. Thanks Regards Prakash Raghavendra -------------- next part

Hi all, I am going to build a Pass/es that verify OpenMP code. When we compile an OpenMP program we give the option “-fopenmp” to clang. In this way the LLVM IR code obtained will reflect also the “#pragma” keywords in the code, let’s call it "OpenMP LLVM IR". In my Pass/es before obtaining the OpenMP LLVM IR, I need to do some operation in the LLVM IR, that is the IR code obtained

Hi, I am instrumenting the stores in a program by inserting a function call (store_prologue) before every store instruction in the IR file. I set the prologue function's attribute to "AlwaysInline" using addFnAttr(). In the program the prologue function is defined as static inline. I am using opt to generate an optimized (inline the calls to the store prologue) using the

Dear R experts, recently I started developing a Rcpp package "OpenMPTest". Within that package I want to use OpenMP, as in the following code example: // header file #include <omp.h> using namespace Rcpp ; RcppExport SEXP testOpenMP( SEXP nThreads ) ; // cpp file SEXP testOpenMP( SEXP nThreads ) { BEGIN_RCPP NumericVector numberThreads = NumericVector( nThreads );

Hi everybody! Could somebody help me with the following? I'm trying to run a simple Hello World code in openmp using .C function. The C code i have is: #include <omp.h> #include <stdio.h> #include <R.h> void hello_omp(int *n) { int th_id, nthreads; omp_set_num_threads(*n); #pragma omp parallel private(th_id) { th_id = omp_get_thread_num();

On 01/16/2012 03:04 AM, Vlad Krylov wrote: > I am interested. I would be grateful for your hints. Great. ;-) > So OpenMP has various constructs such as parallel, barrier, single, > for, etc. And there is at least two libraries to generate OpenMP code: > libgomp and mpc. We want to be independent of specific library. True. > We should create an interface with methods which

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,

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.

Thanks for comments/suggestions. Yes, attaching metadata to instructions will be good choices for many cases. But for loops, attaching metadata to back-edges requires that the front end to build loops, which is an additional task for the front end. And this task is really a backend's job, not the front end's. If the only concern is that it is hard for pragma intrinsics to stay with their