[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#1104685, @hfinkel wrote:

> In https://reviews.llvm.org/D46842#1104559, @Hahnfeld wrote:
>
> > In https://reviews.llvm.org/D46842#1103727, @gtbercea wrote:
> >
> > > Your argument that an older version is better is actually wrong. Using an older version to build the BCLIB is always a BAD idea. The reason why you want to build the BCLIB is so that the runtime functions actually get inlined. If you use an older compiler the functions will not be inlined which defeats the purpose of having the BCLIB in the first place. I stumbled again upon this problem today after updating to the latest changes.
> >
> >
> > To be precise, I didn't say that "an older version is better". My statement was that it works and that older versions of the compiler generate bitcode files that are compatible with a larger number of (newer) compilers.
> >
> > But you are right, inlining of old bitcode files broke last month with https://reviews.llvm.org/rC329829. Luckily, this can be fixed, see https://reviews.llvm.org/D47070.
> >
> > > I do not understand why you are opposing this, so far I haven't heard a single strong argument against this.
> >
> > "strong" is certainly subjective and may imply different things for you and me. If I wanted to put my point to the extreme, I'd say that there is none of your arguments left because I sat down and fixed all the problems you have been describing so far.
> >
> > Coming back to my opinion: I don't like using the just-built compiler because that's not how CMake usually works when you build a project.
>
>
> You're correct, this is not how CMake normally works. However, CMake is also not normally being used to build a compiler. Compiler builds often self host to some degree or another, and the compiler provided to the build system is generally through of only as something necessary to bootstrap the build process. LLVM/Clang, being both a self-hosting compiler and also a library component, has a split personality in this regard. However, in this case, as I believe we do with compiler-rt components, etc., it makes sense to default to using the just-built clang to build the bitcode library (which is intended to be used by that just-built compiler).


I just had a quick look and `compiler-rt` indeed uses the just-built compiler to build instrumented flavors of libc++ that can be used together with the sanitizers. To do so they use the same "trick" as LLVM's `runtimes/` directory, namely CMake's support for external projects. If used correctly CMake can be taught to only rebuild the bitcode library if one of the library's source files changed and not whenever the compiler is rebuilt. That would address one of my largest pain points, maybe that's a compromise? "correctly" turned out to be a bit harder here but I think that code path is only useful for in-tree builds where we can maybe reuse LLVM's CMake modules?

> Honestly, I think we should carefully consider whether we want to officially support a non-version-locked configuration, because if we do, then we need to set parameters on that and test it on the buildbots. My inclination is to officially support on the version-locked configuration between the compiler building the application code, the compiler used to build the bitcode library, and the version of the bitcode library itself.

Good point, we probably should. I would have opted to also allow building with the previous release of Clang, but maybe I can just try to maintain that property on a best effort base. (My use case is that I usually build the `openmp` repository multiple times in different configurations and being able to do that with the latest release during development of the next version would simply things...)


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D46842