search for: hmpp

...t;f" has nested calls of other functions > with "side effects", meaning they could potentially change the contents of > "in" or "out" indirectly. For this reason, even current state-of-art > commercial APIs that imply strong data analysis (like OpenACC or HMPP) > require functions to be free of side effects, because nobody could solve > this problem well at compile-time. > The functions I'm going to analyze are not having side effects (sorry for not mentioning). Basically, they are enclosed kernels. > Depending on the purpose of your q...

..., function "f" has nested calls of other functions with "side effects", meaning they could potentially change the contents of "in" or "out" indirectly. For this reason, even current state-of-art commercial APIs that imply strong data analysis (like OpenACC or HMPP) require functions to be free of side effects, because nobody could solve this problem well at compile-time. Depending on the purpose of your question, this may or may not help: in comparison to general analysis, LLVM community makes way better progress in analysing data access patterns for vector...

...calls of other functions > > with "side effects", meaning they could potentially change the contents > of > > "in" or "out" indirectly. For this reason, even current state-of-art > > commercial APIs that imply strong data analysis (like OpenACC or HMPP) > > require functions to be free of side effects, because nobody could solve > > this problem well at compile-time. > > > > The functions I'm going to analyze are not having side effects (sorry > for not mentioning). Basically, they are enclosed kernels. > > &g...

Hi, suppose the following C function declaration: void f(int *in, int *out); Now further suppose, that _in_ is an array only read from and _out_ is an array that is only written to. Based on this, I was wondering whether there is some already existing LLVM pass (or maybe a part of a pass) that detects those "data directions" for pointers. I'm not quite sure whether e.g. Alias

...ers and researchers. We are mainly focused on our optimized gpu compiler and the HPC market, but also open to sponsoring creative ideas or projects surrounding the gpu. Here's a short list of some of the areas most interesting to us * Nouveau/kernel drivers * CUDA * OpenCL * HMPP * Parallel programming * MPI * Shader compilers If you're interested please contact me offlist with a brief description of your background, the contributions you made to open source and what you'd intend to do with the card. Thanks Christopher #pathscale - irc.freenode.ne...

...ramming models take a significant amount of work. I'm well aware that they can handle at least part of that, but so far I'm not sure who else will invest in it.. The industry has : CUDA, OpenCL, OpenMP4, OpenACC, C++AMP, Parallel STL(??), some research projects from DOE and dead stuff like HMPP... Are all these so broken that they can't be fixed to fill the same necessity as SE? How similar is it to the failed AMD Stream Computing (sorry AMD) http://www.ele.uri.edu/courses/ele408/StreamGPU.pdf Intel's work had to live and grow outside for quite a while - Google may have more goo...

...work. I'm well aware >> that they can handle at least part of that, but so far I'm not sure >> who else will invest in it.. >> >> The industry has : CUDA, OpenCL, OpenMP4, OpenACC, C++AMP, Parallel >> STL(??), some research projects from DOE and dead stuff like HMPP... >> Are all these so broken that they can't be fixed to fill the same >> necessity as SE? > > You're right. SE is certainly different from all of these, higher-level than some and lower-level than others. And, of course, I'm reminded of this: https://xkcd.com/927/ &g...

On Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ________________________________ > > From: "C Bergström" <cbergstrom at pathscale.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" > <cfe-dev at lists.llvm.org>,