similar to: RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

> I'd support some of Jame's comments if liboffload wasn't glued to OMP as it is now. I certainly have no objection to moving liboffload elsewhere if that makes it more useful to people. There is no real "glue" holding it there; it simply ended up in the OpenMP directory structure because that was an easy place to put it, not because that's the optimal place for it.

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, That raises a more meta-question for me, which is “Why should StreamExecutor be in LLVM at all?” AFAICS, with you approach · It is not a runtime library whose interface the compiler needs to understand. · It does not depend on any LLVM runtime libraries. · It is expected to be used with out-of-tree plugins. If I got all of that right, what connection does it

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

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

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

Hi Carlo, Thanks for helping to clarify this point about libomptarget vs liboffload, I have been getting confused about it myself. I think the open question concerns libomptarget not liboffload (others can correct me if I have misunderstood). My analysis from looking through the code was that libomptarget had some similarities with the platform support in SE, so I just wanted to consider how

I did a more thorough read through liboffload and wrote up a more detailed doc describing how StreamExecutor platforms relate to libomptarget RTL interfaces. The doc also describes why the lack of support for streams in libomptarget makes it impossible to implement some of the most important StreamExecutor platforms in terms of libomptarget (

Hola Chandler, On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev < openmp-dev at lists.llvm.org> wrote: > It seems like if the OpenMP folks want to add a liboffload plugin to > StreamExecutor, that would be an awesome additional platform, but I don't > see why we need to force the coupling here. > > Let me give you a reason: while user-facing sides of

Hi Jason, This is probably because I'm not aware of the details, but it was claimed in this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a new library that the compiler has to be aware of has to bring significant benefit. So it is not clear to me yet why the compiler should target two different runtime libraries that seems to have large chunk of overlapping

I created a GitHub repo that contains the documentation I have been creating for StreamExecutor. https://github.com/henline/streamexecutordoc It contains the design docs from the original email in this thread, and it contains a new doc I just made that gives a more detailed sketch of the StreamExecutor platform plugin interface. This shows which methods must be implemented to support a new

Hi Jason, The long discussion made me wondering where this was going, but re-reading you original email [0], there was an acknowledgment of a potential future merge between the projects, and I can of make sense of the current picture. So you can forget about my question below! [0]: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html

We have noticed that although we have active development in the OpenMP runtime, there is no formal code-owner. I would therefore like to nominate Andrey Churbanov who is a major committer and has deep experience with the runtime code since before it was the LLVM runtime. -- Jim James Cownie <james.h.cownie at intel.com> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes) Tel: +44

Hi Reading through the comments: both Chris and Chandler referenced to liboffload, while I thought the subject of conversation was libomptarget and SE. I am being picky about names because liboffload is a library available as part of omp (llvm's openmp runtime library) that, I believe, only targets Intel Xeon Phi. Did you mean liboffload or libomptarget? Thanks -- Carlo From: Alexandre

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

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: "Arpith C Jacob" <acjacob at us.ibm.com> > To: llvm-dev at lists.llvm.org > Cc: jhen at google.com, "Hal J. Finkel" <hfinkel at anl.gov> > Sent: Thursday, March 10, 2016 10:38:46 AM > Subject: Re: [llvm-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries > > Hi Jason, >

Hearing no opinions to the contrary, let's say Banger's 6pm (tomorrow). Address and web site below. I submitted online for a reservation early this morning, and I'll try to get an updated head count on Sunday morning. -Hal Sent from my Verizon Wireless 4G LTE DROID On Nov 14, 2015 11:21 AM, Chandler Carruth <chandlerc at google.com> wrote: Did this ever get settled? On Fri,

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