[RFC]Requiring C++14 for the OpenMP subproject

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.

Jon

    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 would separate these two discussions. One motivation for the relicensing effort is to allow sharing code between runtime libraries and the core infrastructure.

Ah, yes. License differences would explain it. I’ll have to catch up on where relicensing has got to. Thanks!