similar to: [LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM

On 15 August 2012 11:04, Raghavendra, Prakash <Prakash.Raghavendra at amd.com> wrote: > My idea is to capture parallelism with the way you have said using > ‘metadata’. I agree to record the parallel regions in the metadata (as given by the user). However, we > could also give placeholders to record any additional information that the compiler writer needs like > number of

Chirs, Have you seen an offloading infrastructure design proposal at http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084986.html ? It relies on the long-standing OpenMP standard with recent updates to support the heterogenous computations. Could you please review it and comment on how it fits to your needs? It's not quite clear from your proposal what source language standard do you

Roel, You have to checkout and build llvm/clang as usual. For runtime support you'll have to build the libomptarget and make a plugin for your target. Samuel can help you some more. As for the OpenMP examples I can recommend you the http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf look into the target constructs. Sergos On Mon, Jun 8, 2015 at 6:13 PM, Roel Jordans <r.jordans at

On Mon, 13 Aug 2012 12:38:02 +0300 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi, > > On 08/10/2012 11:06 PM, Hal Finkel wrote: > > I'd like to see support in clang/LLVM for multi-core parallelism, > > especially support for OpenMP. I think that the best way to do > > this is by designing an LLVM-based API (metadata and intrinsics) >

On 08/13/2012 10:54 PM, Hal Finkel wrote: > I had thought about uses for shared-memory OpenCL implementations, but > I don't know enough about the use cases to make a specific proposal. Is > your metadata documented anywhere? It is now a quick "brute force hack", that's why I got interested in your proposal. We just wanted to communicate the OpenCL work item information

Hi Sergos and Samuel, Thanks for the links, I've got it mostly working now. I still have a problem with linking the code. It seems that the clang driver doesn't pass its library search path to nvlink when linking the generated cuda code to the target library, resulting in it not correctly finding libtarget-nvptx.a. Is there some flag or environment variable that I should set here?

Christos, We would be very interested in learning more about this. In my group, we (Prakalp Srivastava, Maria Kotsifakou and I) have been working on LLVM extensions to make it easier to target a wide range of accelerators in a heterogeneous mobile device, such as Qualcomm's Snapdragon and other APUs. Our approach has been to (a) add better abstractions of parallelism to the LLVM instruction

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, On 08/10/2012 11:06 PM, Hal Finkel wrote: > I'd like to see support in clang/LLVM for multi-core parallelism, > especially support for OpenMP. I think that the best way to do this is > by designing an LLVM-based API (metadata and intrinsics) for > expressing parallelism constructs, and having clang lower OpenMP code > to that API. This will allow maximal preservation

Hello, OpenCL C specifies that instructions should not trap (it is "discouraged" in the specs). If they do, it's vendor-specific how the hardware exceptions are handled. It might be also the case with some other (future) languages targeting "streamlined" parallel accelerators in an heterogeneous setting. At least CUDA comes to mind. What about OpenACC and the new OpenMP,

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

On Wed, Jun 1, 2016 at 8:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> 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>, "openmp-dev"

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>,

Hello, I'd like to see support in clang/LLVM for multi-core parallelism, especially support for OpenMP. I think that the best way to do this is by designing an LLVM-based API (metadata and intrinsics) for expressing parallelism constructs, and having clang lower OpenMP code to that API. This will allow maximal preservation of optimization capabilities including target-specific lowering. What

Dear community, In preparation for the BoF on Parallel IR at the US developers meeting we would like to collect feedback from the whole community. The concerns, ideas, etc. will be summarized in the BoF and should provide a good starting point for a discussion. We know that over the years the topic of a parallel extension for LLVM was discussed on the mailing list [0, 1, 2], workshops [3, 4] or

On Wed, Jun 1, 2016 at 11:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> 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>, "openmp-dev"

Chandler, Thank you for getting it up to ML top. I believe we have to move broader than that you just mentioned. The natural separation of the infrastructure into different parts can be across the following lines: - the parallel model of programming - these can be OpenMP, OpenACC, CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc. - the offloading machinery to be used by any

Hi Tobi Thanks a lot for your detailed update on the status of OpenMP in LLVM. It looks like there is no "official" support of OpenMP in LLVM 3.x at least. In your descriptive list, I can see that [a] is an optional patch or available in GCC, [b] & [c] are available as optional runtimes (which have to be carefully bundled). [d] anyway is little different from OpenMP (can exist

Hi Pekka, The motivation for the ’notrap’ bit is clear. Domain specific languages can set this bit to enable more aggressive optimizations. I don’t think that the Loop Vectorizer is a good example because it is not designed to vectorize data-parallel languages which have a completely different semantics. In OpenCL/Cuda you would want to vectorize the outermost loop, and the language

After reading about Intel's 'Shevlin Park' project to implement C++AMP in llvm/clang, and failing to find any code for it, I decided to try to implement something similar. I did it as an excuse to explore and hack on llvm/clang, which I hadn't done before, but it's now at the point where it will run the simplest matrix multiplication sample from MSDN, so I thought I might