[llvm-dev] Orc JIT Layering

[David Blaikie via llvm-dev]

Seems one of the latest Orc changes (
https://github.com/llvm/llvm-project/commit/99a6d003edbe97fcb94854547276ffad3382ec1d
) while not itself changing/breaking the layering in LLVM's own build, it
has revealed some pre-existing problems with the layering that we'd worked
around at Google in a way that isn't viable after this recent change.

One immediate/easily observed issue: lib/ExecutionEngine's CMakeLists.txt
says it depends on OrcTargetProcess, but OrcTargetProcess includes
lib/ExecutionEngine/JITSymbol.h

The only common dependency for all the uses of JITSymbol.h seems to be
llvm/Support (ie: without introducing new dependencies or new libraries,
JITSymbol.h would need to be moved to llvm/Support to fix this particular
dependency cycle/issue)

We do have a bunch of other workarounds for Orc layering in the Google
internal build system too - so perhaps I can enumerate some/all of the
issues here, as it might be best to take a holistic approach to fixing
these issues.

Let's see what I can document/figure out...

ExecutionEngine/Orc -> ExecutionEngine
ExecutionEngine/Interpreter -> ExecutionEngine
ExecutionEngine/RuntimeDyld -> ExecutionEngine
ExecutionEngine/IntelJITEvents -> ExecutionEngine
ExecutionEngine/OProfileJIT -> ExecutionEngine
ExecutionEngine/PerfJITEvents -> ExecutionEngine
ExecutionEngine/MCJIT -> ExecutionEngine

And there's actually no #includes in ExecutionEngine that reference those
libraries, so that's pretty good.

It is this CMakeLists.txt dependency from ExecutionEngine to
OrcTargetProcess. Which happens without a #include:

$ grep -r "void __jit_debug_register_code" llvm/

llvm/lib/ExecutionEngine/GDBRegistrationListener.cpp:  extern "C" *void
__jit_debug_register_code*();

llvm/lib/ExecutionEngine/Orc/TargetProcess/JITLoaderGDB.cpp:LLVM_ATTRIBUTE_NOINLINE
*void __jit_debug_register_code*() {

Would be better if this wasn't declared arbitrarily (instead, if it was
declared in a header and defined as usual, the circular dependence would be
more clear, I think?) - but either way, the circular dependency needs to be
fixed.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210302/ac88889b/attachment.html>