[Openmp-commits] [PATCH] D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available

[Jonas Hahnfeld via Phabricator via Openmp-commits]

Hahnfeld added a comment.

In https://reviews.llvm.org/D46842#1098482, @gtbercea wrote:

> The just-built compiler is a reasonable default in my opinion. I don't see a downside to it.


I'll try to summarize some points that I said on other patches and that come to my mind:

1. The just-built compiler doesn't exist by definition when CMake is invoked. This will prevent all kind of dynamic flag checking (Does `${LIBOMPTARGET_NVPTX_SELECTED_CUDA_COMPILER}` support `-fflag`?). This is how I propose to reliably implement a solution for https://reviews.llvm.org/D44992.
2. See the quote in my previous comment: This patch will result in rebuilding the entire library whenever there is a change in LLVM or Clang. While this doesn't seem to problematic at first, `clang` is usually the binary that finishes linking last because it's rather large. So the compilation of `libomptarget-nvptx-bc` can only start after almost all other steps of the build are done. I've found this really annoying in the past.
3. There is a somewhat weaker problem when looking in the other direction: Let's say you have a fully setup LLVM build, but only want to build `libomptarget-nvptx-bc` (for whatever reason; let's just assume you are doing some changes in there that you want to test). This will result in the build system compiling the entire compiler before actually starting to build the library. I acknowledge that this will only happen after changes to files in LLVM or Clang, but if you synchronize to the latest changes once a day you can basically sit there and wait for your build to complete at the start of your working day.

In https://reviews.llvm.org/D46842#1098493, @gtbercea wrote:

> There is a very good reason why the current compiler is being used for compiling the bc-lib. Any incompatibility in LLVM version between the bclib compiler and the just-built compiler will result in an error when inlining due to different LLVM versions.


>From what I read in the documentation the LLVM bitcode should be compatible with all versions down to LLVM/Clang 3.0. Is there a particular problem that you have in mind?

In https://reviews.llvm.org/D46842#1098482, @gtbercea wrote:

> George, I am well aware of the long-way and that is exactly what I'm trying to avoid.


For production installations I'd say that's the way to go anyway. If you really want to use the just-built compiler during a single run, you should take a look at LLVM's `runtimes/` directory which does all that while taking care of most problems. For example, it will only run CMake once `clang` has been compiled for the first time and the build system will correctly handle incremental builds. However, I'm not sure if it recompiles the libraries after there was a change to the compiler. But there have been some smart people thinking about this (namely Chris Bieneman and Petr Hosek) so I think the build system now probably does "The Right Thing" (tm).


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D46842