I'd like to better understand the structure of the ORC runtime and its dependencies (both build and runtime). Does it use the C or C++ standard library? Does it depend on other parts of LLVM? Do you plan on reusing some of the existing compiler-rt libraries like sanitizer_common?
To give a bit more background on why I'm interested, compiler-rt has grown fairly organically this has been making the maintenance more and more difficult, at least from the build perspective. There are some runtimes that only use C, some that use C++, some that use C++ standard library. When building compiler-rt together with other runtimes like libc or libc++, it's difficult to pick up the right order which is why we have several entry points into compiler-rt's build system to build different subsets and that's been a maintenance headache.
I've been thinking about this quite a bit recently and I repeatedly came to the conclusion that compiler-rt would ideally be broken up into several subprojects, but that should probably be discussed as a separate topic. However, understanding the build and runtimes dependencies of the ORC runtime could help us decide whether it should be a part of compiler-rt or be a separate subproject.
Hi Petr,I'd like to better understand the structure of the ORC runtime and its dependencies (both build and runtime). Does it use the C or C++ standard library? Does it depend on other parts of LLVM? Do you plan on reusing some of the existing compiler-rt libraries like sanitizer_common?The ORC runtime currently uses the C++ standard library.Since the ORC runtime needs to communicate with the LLVM ORC library it also currently uses some header-only includes from LLVM. It does not depend on any LLVM libraries. We could duplicate this code, but I'd prefer to share it if possible.I have not used sanitizer_common, but some parts of it look like they may be useful.I gravitated towards implementing the ORC runtime in compiler-rt because I need to be able to write parts of it in platform-specific assembly (which compiler-rt supports), and because the runtime should be build for all targets, not just the host (which seems to be the standard way that compiler-rt is configured).
From this it sounds like "convenient reusing of the build system" rather than "should be included in compiler-rt as a library"? If that's the case maybe making it clear or lifting the common build system support out might be maintainable without the "this is a runtime library for the system" sort of thing?
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Arguments in favor are that the build requirements are very similar, and there are some conceptual parallels (the ORC runtime is providing implementations for entry points generated by the compiler and linker, among other things). On the other hand the implementations are all JIT specific, which is definitely different from everything else in compiler-rt.
The primary difference, at least from my perspective, is that the ABI between the compiler and compiler-rt is unstable and these runtimes are version locked to the compiler...
This can help guide the appropriate location for ORC runtime, but as you can also see, there are no hard rules and either compiler-rt or a standalone top-level project can be made to work.
If we decide to go with a new top-level project, I wouldn't try to reuse compiler-rt CMake build. That build has a number of issues which we're trying to fix but it might take a while before the situation improves. Instead, I'd start with the simplest possible CMake setup and then see if you could reuse common parts of libc and libcxx builds, and if so we can extract those into a common location as needed.
I'd like to see that support even for other runtimes because we already have a use for it...
Ok, so you’re saying you want it to be part of the llvm/llvm-project/tree/main/compiler-rt tree, but not part of the compiler_rt library itself, got it.
Does compiler-rt currently depend on LLVM libraries? Does this change the dependence graph of the llvm and compiler-rt subproject?
Though now that I think about it, I think there is /something/ shared
between compiler-rt and LLVM - for xray and instrumented profiling, I
think there are some common constants or data structures or something.
Might be worth checking how those work?
On Sat, Apr 24, 2021 at 2:10 PM Lang Hames via llvm-dev
Yeah, for buildability (for instance, Google's build system doesn't
have any special dispensations for header only libraries - doesn't
allow arbitrary includes without dependencies - and I think this is
generally a good thing) it's probably best/necessary to duplicate.
Though now that I think about it, I think there is /something/ shared
between compiler-rt and LLVM - for xray and instrumented profiling, I
think there are some common constants or data structures or something.
Might be worth checking how those work?
InstrProfData.inc is shared between LLVM and compiler-rt:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ProfileData/InstrProfData.inc
https://github.com/llvm/llvm-project/blob/main/compiler-rt/include/profile/InstrProfData.inc
There's no special mechanism to keep those in sync, we manage them manually.