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

[Mehdi Amini via llvm-dev]

> On Mar 28, 2016, at 10:18 AM, C Bergström <cbergstrom at pathscale.com> wrote:
> 
> On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> 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
>> functionalities.
>> On a high-level view, these libraries seems to have the same goals with
>> respect to what they provide to the compiler.
>> 
>> Can you elaborate?
> 
> (Ignore this please)
> 
> To butt in with a peanut gallery comment - I suspect it's because
> liboffload is really just providing a bare set of non-portable API
> mostly tailored to OpenMP4.

That can be a valid argument. If indeed liboffload is limited by its original design and a new design can be useful to a wider range of model/target, then the path forward should rather be to replace liboffload. 
IMO, duplicating libraries/API that the compiler has to be aware of should be really motivated by specificities provided by each library that can't be unified in a single library/API.

-- 
Mehdi

 


> Having it support any other programming
> model is probably going to take real work on the part of refactoring
> "liboffload". (*cough* *cough* good design)
> 
> In the end I pessimistically suspect each programming model wanting
> inclusion will reinvent the wheel and make the same argument each
> time. So we'll end up with lots of libraries doing mostly the same
> thing, duplicate code/support.. etc