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

[C Bergström via llvm-dev]

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 behaviour
---------
If my points above are invalid - can someone clarify that SE and the
"stuff" in OpenMP-llvm doesn't actually overlap in functionality.




On Mon, Apr 25, 2016 at 11:46 PM, Chandler Carruth via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>