similar to: [LLVMdev] [RFC] OpenMP offload infrastructure (iteration 2)

Hi Sergey, Thanks for putting the new version of the document together! I don't see any other issues. I strongly believe the approach described in the document is a nice way to get OpenMP offloading support in clang. I plan to start actively contributing code for this component of the OpenMP implementation soon. Thanks again, Samuel 2015-04-29 11:47 GMT-04:00 Sergey Ostanevich

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?

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

Hello everybody! I would like to present a proposal for implementation of OpenMP offloading in LLVM. It was created by a list of authors and covers the runtime part at most and at a very high level. I believe it will be good to have input from community at this early stage before moving deeper in details. The driver part is intentionally not touched, since we have no clear vision on how one can

Hi John, Thank you for the comments. I am addressing some of them bellow. Regards, Samuel 2014-08-11 9:36 GMT-04:00 John Leidel (jleidel) <jleidel at micron.com>: > Sergey [et.al], thanks for putting this proposal together. Overall, this > looks like a pretty solid approach to providing relatively hardware > agnostic omp target functionality. I had several comments/questions

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

On 08/11/14 01:03 PM, Das, Dibyendu wrote: > I didn’t see SPIR discussed anywhere. This isn't OpenCL and depending on OpenCL for OpenMP may not really make sense. While I have my own opinions - If you feel strongly that it will help enable higher performance somewhere please list those reasons. ---------- More specifically LLVM has a native AMD dGPU backend that is tightly coupled to the

Dmitrii, all, Please note, that GCC 5.3 had a significant update to the MPX code quality - please, use this version as reference. Regards, Sergos On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Thu, Feb

Hi Sergos, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? If I

Jason, > If I understand your interpretation of streams, it does not match my > understanding. SE follows the CUDA meaning of "stream". I think of a stream > as a "work queue" and each device can have several active streams. Memory > space on the device does not belong to any stream, so any stream can access > it. The thing that does belong to the stream is the

Hello, even though the study of Intel MPX took much longer than expected, we have finally finished it. Currently, it is published in two formats: * as a technical report: https://arxiv.org/abs/1702.00719 * and as a webpage: https://intel-mpx.github.io/ This work contains evaluation of MPX from perspectives of performance (Phoenix, PARSEC, and SPEC benchmark suites), security (RIPE and found

On 08/11/14 07:32 PM, Das, Dibyendu wrote: > Storing llvm-ir in the fat binary may have the same performance issues mentioned below. The fat binary discussed in the proposal has provision for storing the isa/llvm-ir. My point is instead of llvm-ir it shd be something like spir. Ok - so lets see some data. #1 Benchmarks showing at least SPIR dgemm/sgemm performance #2 Some logical explanation

Jason, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? Regarding

Am I mistaken in that some .c files must actually be compiled as c++? In file included from openmp-llvm/runtime/src/kmp_ftn_cdecl.c:16: openmp-llvm/runtime/src/kmp.h:210:3: warning: redefinition of typedef 'ident_t' is a C11 feature [-Wtypedef-redefinition] } ident_t; ^ ---------- I previously sent a patch that fixes this and it was completely rejected. IMHO - This must be fixed 1) C

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

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:52:38 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input

On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> wrote: > Congratulations! Would you like to add a blurb to the release notes > for the next release? Sure! Will do. Yours, Andrey

It will come on next week. I'd like to give a chance to everyone to raise their objections first. Yours, Andrey > 8 мая 2015 г., в 18:30, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Is there a proposed patch yet for switching the -fopenmp support over > to the openmp library instead of libgomp? I realize the call to rename > the library may be

Alexandre, Thanks for further shedding some light on the way OpenMP handles dependencies between tasks. I'm sorry for leaving that out of my document, it was just because I didn't know much about the way OpenMP handled its workflows. On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote: > Hi Carlo, > > Thanks for helping to clarify this point about

No, just changing defaults -- subject to code reviewers approval. As I said before, I prefer to leave library naming to library pros. Andrey On Fri, May 8, 2015 at 7:21 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > So you plan on switching and enabling the openmp library defaults as > well as changing the openmp library name at the same time? > Jack >