similar to: [LLVMdev] [RFC] OpenMP offload infrastructure

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

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

Hello everybody! To continue the original (http://article.gmane.org/gmane.comp.compilers.llvm.devel/75674) discussion of offload infrastructure I have an updated document with more details for your attention. The document is a consensus of the contributors representing a number of institutions: ANL, AMD, IBM, Intel and Texas Instruments. Our intent is to have a discussion and an approval from

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

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

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

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

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

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

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

I think it would be great if StreamExecutor could use liboffload to perform its offloading under the hood. Right now offloading is handled in StreamExecutor using platform plugins, so I think it could be very natural for us to write a plugin which basically forwards to liboffload. If that worked out, we could delete our current plugins and depend only on those based on liboffload, and then all the

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 Andrey, Sorry, I definitely misspoke when I said it was likely for OpenMP stuff to end up in this new project. I meant to say that it was possible in the long run, but there are no plans for that now. On Thu, Jun 16, 2016 at 11:55 AM Andrey Bokhanko <andreybokhanko at gmail.com> wrote: > On Thu, Jun 16, 2016 at 9:05 PM, Jason Henline via Openmp-dev < > openmp-dev at

I can't comment on all the things not directly used by llvm community, but I feel pretty strongly that 1) An independent project like liboffload should exist ; which 2) Projects like SE and OpenMP should both be using it ; and further 3) SE shouldn't just do their own thing because they haven't figured out how to make it work with other projects that already have some overlapping

On Thu, Jun 2, 2016 at 11:47 AM, Chandler Carruth <chandlerc at google.com> wrote: > (Mostly trying to re-focus the thread somewhat) > > Given support from Mehdi, Renato, and especially Hal who has contributed > specifically in this area to LLVM as a whole, and no strong objections from > significant contributors (I feel like the primary concerns Intel raised have > been

Hi Arpith, That is exactly what it is :). My bad, I thought I copied over the libraries to where LIBRARY_PATH pointing but apparently it was copied to a wrong destination. Thanks a lot. On Wed, Jan 20, 2016 at 4:51 AM, Arpith C Jacob <acjacob at us.ibm.com> wrote: > Hi Ahmed, > > nvlink is unable to find the GPU OMP runtime library in its path. Does > LIBRARY_PATH point to

Thanks for the reply! It sounds like LLVM IR is being considered for optimizations in OpenMP constructs. There seems to be plans regarding improvement of LLVM IR Framework for providing things required for OpenMP / flang(?) Are there any design considerations which contain pros and cons about using the MLIR vs LLVM IR for various OpenMP related optimizations/ transformations? The latest RFC [

Hi, I have few questions / concerns regarding the design of OpenMP dialect in MLIR that is currently being implemented, mainly for the f18 compiler. Below, I summarize the current state of various efforts in clang / f18 / MLIR / LLVM regarding this. Feel free to add to the list in case I have missed something. 1. [May 2019] An OpenMPIRBuilder in LLVM was proposed for flang and clang frontends.