[PATCH] D51744: [WIP] Early ThinLTOLayer2 prototype

[Stefan Gränitz via Phabricator via llvm-commits]

sgraenitz added a comment.

TEST INSTRUCTIONS
I am aware that this must change in case it gets upstreamed some day. Still, if you have a good idea how I could do this properly with gtest, please let me know. Also note, that the `.ll` files include target-specific information from my system.

  $ ninja OrcJITTests
  $ ninja llvm-as
  $ bin/llvm-as ../llvm/unittests/ExecutionEngine/Orc/Inputs/Bar.ll -o unittests/ExecutionEngine/Orc/Bar.bc
  $ bin/llvm-as ../llvm/unittests/ExecutionEngine/Orc/Inputs/Foo.ll -o unittests/ExecutionEngine/Orc/Foo.bc
  $ unittests/ExecutionEngine/Orc/OrcJITTests -debug -debug-only orc-thinlto-layer --gtest_filter=LookupOrders/ThinLTOLayer2Test.*



================
Comment at: lib/ExecutionEngine/Orc/Core.cpp:49
+    OS << "[Materializing]";
+
   return OS;
----------------
This helped me a lot in debugging.


================
Comment at: lib/ExecutionEngine/Orc/Core.cpp:1353
+}
+
 void JITDylib::lodgeQueryImpl(
----------------
The hack I referred to in the summary. The straightforward solution would be another extension point in the API (callback or something), but I wonder if we could even keep the GUIDs and do this in the resolver?


================
Comment at: lib/ExecutionEngine/Orc/Core.cpp:1403
       // materializing state.
-      for (auto &KV : MU->getSymbols()) {
+      for (const auto &KV : MU->getSymbols()) {
         auto SymK = Symbols.find(KV.first);
----------------
@lhames This may aid readability, as it's easy to confuse which symbols/symbol flags are modified here.


Repository:
  rL LLVM

https://reviews.llvm.org/D51744