[Openmp-dev] [RFC]Requiring C++14 for the OpenMP subproject

[Hal Finkel via Openmp-dev]

On 2/11/20 7:50 AM, Jim Cownie via Openmp-dev wrote:
>> On 2/11/20 4:56 AM, Jon Chesterfield via Openmp-dev wrote: >//>/Hmm, 
>> so you propose creating a dependency from the OpenMP runtime to 
>> />/the LLVM libraries? Which classes would you want to use, probably 
>> some />/of the ADTs? Does any of the other runtime libraries (libc++, 
>> />/libc++abi, compiler-rt, sanitizers) already do this? IIRC 
>> />/libc++abi and />/LLVMSupport share some demangling code, but that 
>> is manually copied. />//>//>/I am unaware that each subproject 
>> reimplements code to avoid a />/dependency on llvm. My first reaction 
>> is "surely not", but it's not />/totally implausible. I will look 
>> into this. />//>/ADT is the obvious contender for reuse. There will 
>> also be a lot of OS />/wrappers somewhere. File IO, dlopen, probably 
>> memory allocators. />/Essentially all the stuff a big cross platform 
>> C++ project grows over />/time. In the case of anything hitting the 
>> filesystem, also />/treacherously difficult to get right across 
>> platforms. />//>/There's an open patch against libomptarget that uses 
>> dlopen with a />/hardcoded path length. Opt loads shared libraries on 
>> windows afaik so />/probably has a robust wrapper around dlopen, so 
>> I'd start there. / I would separate these two discussions. One 
>> motivation for the relicensing effort is to allow sharing code 
>> between runtime libraries and the core infrastructure. I expect that, 
>> as we move to full coverage on various parts of the relicensing, 
>> we'll have a large-scale discussion about how to implement this 
>> resuse across the project. However, we can certainly use C++14 
>> language features before we worry about using LLVM's support library. 
>>  -Hal 
> I agree wth Hal; there are two different issues here which have 
> potentailly different implications :-
>
>  1. Choice of base language level (C++11 or C++14)
>  2. Moving code backwards and forwards between the runtime and the
>     compiler, or adding additional runtime library requirements on
>     users of the OpenMP runtime.
>
>
> Changing the language dialect seems a small an uncontentious thing to do.
> However adding additional dependencies seems more problematic. It is 
> important that the runtime should remain usable with code compiled by 
> GCC, for instance, even in the absence of other libraries. So not just 
> that we support GCC’s OpenMP interfaces when we’re dealing with, say, 
> an OpenMP program compiled by LLVM which links to a GCC compiled 
> library that uses OpenMP, but also an all GCC case, where nothing but 
> libomp has been compiled by LLVM.
>
> This matters because libomp can provide useful performance 
> improvements over libgomp at high core counts, and that is useful to 
> some people.
> It’s also a nice sales-pitch for LLVM in general :- “Look, you were 
> able to use some of LLVM without even recompiling your GCC compiled 
> code, and it improved the performance. Just think how good it could be 
> if you moved to LLVM completely…” :-)


Indeed :-)

In practice, when we discuss using the LLVM support library in the 
runtime libraries, I expect that we'll also have some discussion on how 
it should be split, or not, how it should be linked (statically, 
dynamically, whatever), what dependencies it may have. I expect that we 
would want this to be pretty transparent when we do it.

  -Hal


>
>
> -- Jim
> James Cownie <jcownie at gmail.com <mailto:jcownie at gmail.com>>
> Mob: +44 780 637 7146
>
>
>
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200211/747a52a1/attachment-0001.html>