[Openmp-commits] [PATCH] D101265: [OpenMP][CMake] Use in-project clang as CUDA->IR compiler.

Mon Apr 26 17:22:33 PDT 2021

Meinersbur added a comment.

In D101265#2715759 <https://reviews.llvm.org/D101265#2715759>, @tianshilei1992 wrote:

> In D101265#2715749 <https://reviews.llvm.org/D101265#2715749>, @Meinersbur wrote:
>
>> In D101265#2715714 <https://reviews.llvm.org/D101265#2715714>, @tianshilei1992 wrote:
>>
>>> If OpenMP is built via `LLVM_ENABLE_PROJECTS`, it is *intentional* to build OpenMP w/o using the clang in recent build.
>>
>> Is this documented somewhere?
>
> You could refer to https://llvm.org/docs/CMake.html for `LLVM_ENABLE_PROJECTS` and https://llvm.org/docs/BuildingADistribution.html for `LLVM_ENABLE_RUNTIMES`.

The first link does not mention what is intended to build with what compiler.
The second link is for creating a distributable package, which does not apply here.

>> Would you require the buildbot to do a stage1 build first for a LLVM_ENABLE_PROJECTS=openmp build?
>
> It depends. If you want offloading feature, then it requires. If you don't want that, it doesn't.

It is not required, it works without a stage1 build and this patch.

> For example, for `LLVM_ENABLE_PROJECTS=clang`, we don't expect to build clang with the "recent built" clang, right?

We expect `.td` files to be built with recent built tablegen.

> If you need it to be built with the recent build Clang, then `LLVM_ENABLE_RUNTIMES` is for that purpose. 
> Why not go with `LLVM_ENABLE_RUNTIMES`?

That is another configuration: http://meinersbur.de:8011/#/builders/143 (The `LLVM_ENABLE_PROJECT` configuration is http://meinersbur.de:8011/#/builders/142)

I would like to test both.

There are valid use cases for using a LLVM_ENABLE_PROJECT configuration. One is that it is a single build dir for using in an IDE or generating a single CMAKE_EXPORT_COMPILE_COMMANDS for use with tools such as clangd. Ninja can also better track dependencies. libomp(target?) is also used by non-Clang compilers such as icc and msvc.

> I suppose you are building LLVM with GCC. If you're building LLVM with LLVM, offloading support will also be enabled. The idea here is, the OpenMP is built using the same compiler to build LLVM. Basically the OpenMP project will be built in a same way as others.

The OpenMP host code, but CMake does not configure a device RTL compiler. I would not expect it to use the host compiler for cross-compiling to the GPU. That's what a cross-compiler is for.

Another difference is while for assembly we have a well-defined ABI that ensures that outputs from different compilers are compatible, mixing BC files from different versions of LLVM might not be such a good idea. Sure, there is the AutoUpgrader, but it's probably one of the least tested components in LLVM. Then there are also future versions or third-party forks of clang who's BC files might not at all compatible with our clang, e.g. Apple's clang.

LLVM_ENABLE_RUNTIMES also seems badly documented. When it was first introduced, it did not work for a couple of years and I only found out relatively recently that it is supposed to work. And I am not the only one <https://lists.llvm.org/pipermail/llvm-dev/2021-March/148980.html>. A newcomer will first try `LLVM_ENABLE_PROJECT=clang;openmp` and be frustrated to see that it will not work with a cryptic error message

  No library 'libomptarget-nvptx-sm_61.bc' found in the default clang lib directory or in LIBRARY_PATH. Please use --libomptarget-nvptx-bc-path to specify nvptx bitcode library.

These problems can all be avoided by using the "recent built" clang as a sensible default. You can still use another by explicitly setting LIBOMPTARGET_NVPTX_CUDA_COMPILER.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101265/new/

https://reviews.llvm.org/D101265