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

[Chandler Carruth via llvm-dev]

On Mon, Apr 25, 2016 at 11:41 AM Sergey Ostanevich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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 of those above and providing
> unified interfaces across all targets to be supported
> - the performance libraries collection that can be re-used in different
> programming models and be targeting different host/targets planforms
>
> I would like to touch the 2nd bullet, since I had most exerience with
> it.There should be a single interface for all offloading players that are
> willing to take part. Those are not limited to StreamExecutor and the
> OpenMP already published in LLVM. There are number of solutions from Intel,
> not saying of others, - it would be reasonable to become a platform for all
> of them, and I got positive feedback on the idea within.
> To name a few (don't take it as an ad):
>
>  - Hetero Streams Library, https://01.org/hetero-streams-library
>  - Beignet Project, https://01.org/beignet
>  - Math Kernel Libraries, https://software.intel.com/en-us/intel-mkl
>  - Intel Compiler, https://software.intel.com/en-us/intel-compilers
>
> I believe we shouldn't make any difference between StreamExecutor and
> other projects and to try to plug one into the other or vice versa. The
> better would be to reuse the same ground level I/O machinery that will
> provide efficiency to all of these and the newcomers. The machinery should
> have some specific attributes, such as support of multitude of languages
> currently employed by LLVM project and beyond. Also we have to take into
> account different application of the compiler and infrastructure: there can
> be server solutions where we are free to use full-featured C++ and there
> can be embedded solutions, such as automotive, where customers are tend to
> have as few runtime support as possible and like C the most.
>

I don't think anything I'm suggesting precludes these directions in the
future?

I just don't think it is reasonable to hold up starting to work on the
pieces that are ready now. OpenMP was ready some time ago and is making
fine progress. StreamExecutor is ready now, and I'd like to let it make
progress indepnedently. If and when unifying infrastructure and sharing it
across a diverse set of technologies like this is desirable, we can figure
out the design with concrete patches and steps to get there? It seems *way*
too early to try to design for all of the things you list considering that
many aren't even in LLVM currently.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/cbb59ac6/attachment.html>