llvm dev - Mar 2016 - [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

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 have with LLVM that makes
having it in the LLVM tree necessary, or an improvement over simply having it on
github (or whatever your favourite open-source hosting location is)?

Did I misunderstand something?

-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Tuesday, March 15, 2016 10:44 AM
To: Jason Henline <jhen at google.com>; C Bergström <cbergstrom at
pathscale.com>; Cownie, James H <james.h.cownie at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at
lists.llvm.org>; openmp-dev at lists.llvm.org
Subject: Re: [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for
parallelism runtime and support libraries

On Mon, Mar 14, 2016 at 6:51 PM Jason Henline via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
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.

I think that having a liboffload plugin would be nice, but I don't think we
should really base everything on top of this for a few reasons:

1) I think we already have a nice plugin interface specifically designed to
support out-of-tree platforms with StreamExecutor, and it wouldn't make a
lot of sense to force them to re-implement there stuff.

2) Some platforms may not want or be able to use the liboffload style plugin.

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.

My 2 cents.
-Chandler
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160315/e527d0d6/attachment-0001.html>

On Tue, Mar 15, 2016 at 12:13 PM Cownie, James H <james.h.cownie at
intel.com>
wrote:
> 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.
>
The original email pretty clearly spells out how it is specifically
intended to be a target for the compiler?

> ·         It does not depend on any LLVM runtime libraries.
>
> ·         It is expected to be used with out-of-tree plugins.
>
Note that this doesn't mean there won't be in-tree plugins. It's
analogous
to how LLVM supports out-of-tree targets.
>
>
> If I got all of that right, what connection does it have with LLVM that
> makes having it in the LLVM tree necessary, or an improvement over simply
> having it on github (or whatever your favourite open-source hosting
> location is)?
>
If there were nothing compiler related to it, then the argument would be
much more tenuous. But I think there is a great deal of compiler relevance
here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160315/0c0c9de3/attachment.html>

OK, thanks.

-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Tuesday, March 15, 2016 11:28 AM
To: Cownie, James H <james.h.cownie at intel.com>; Jason Henline <jhen
at google.com>; C Bergström <cbergstrom at pathscale.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at
lists.llvm.org>; openmp-dev at lists.llvm.org
Subject: Re: [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for
parallelism runtime and support libraries

On Tue, Mar 15, 2016 at 12:13 PM Cownie, James H <james.h.cownie at
intel.com<mailto:james.h.cownie at intel.com>> wrote:
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.
The original email pretty clearly spells out how it is specifically intended to
be a target for the compiler?


•         It does not depend on any LLVM runtime libraries.

•         It is expected to be used with out-of-tree plugins.
Note that this doesn't mean there won't be in-tree plugins. It's
analogous to how LLVM supports out-of-tree targets.

If I got all of that right, what connection does it have with LLVM that makes
having it in the LLVM tree necessary, or an improvement over simply having it on
github (or whatever your favourite open-source hosting location is)?
If there were nothing compiler related to it, then the argument would be much
more tenuous. But I think there is a great deal of compiler relevance here.
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160315/671cf0ee/attachment.html>