This is an archive of the discontinued LLVM Phabricator instance.

[WIP][ORC][ThinLTO] Early ThinLTO-JIT prototype and basic tests for next-gen ORC APIs
AbandonedPublic

Authored by sgraenitz on Aug 30 2018, 10:37 AM.

Details

Reviewers
lhames
Summary

Mimimal implementation that I could use to demonstrate speedups. Will add inline comments where I think this is not satisfying yet. Apart from that, what do you think? Do you have proposals for improvements?

Originally I wanted a real ThinLTOLayer with a proper ThinLTOLayerMaterializationUnit, integration with llvm::orc::lookup(), etc. So far I failed to get the SymbolFlags handling right, when passing the MaterializationResponsibility down to the underlying IRLayer. Would be great to fix that and upstream it, but it's no hurry.

Diff Detail

Event Timeline

sgraenitz created this revision.Aug 30 2018, 10:37 AM

Not sure what's the best way to get rid of the binary object files. IIUC the ThinLTO tests are lit-based, so they build their summary-enhanced objects with clang and test via llvm-lto2 tool. Maybe I can turn all the unit tests into lit-test and add a hook to llvm-lto2? Don't know if there is a way to emit object files with summaries using yaml2obj or so? Any ideas?

lib/ExecutionEngine/Orc/LLThinLTOJIT.cpp
154

It's not currently possible to obtain the SearchOrder to check for existing entries. That's on purpose?

unittests/ExecutionEngine/Orc/LLThinLTOJITTest.cpp
230

I think I could do much better here with an actual layer. It currently dumps:

[ RUN      ] LLThinLTOJITTest.Incomplete
JIT session error: Symbols not found: { "_bar" }
Failed as expected: Failed to materialize symbols: { "_foo" }
Failed again: Symbols not found: { "_foo" }
[       OK ] LLThinLTOJITTest.Incomplete (11 ms)

With control over the MaterializationUnit, I could invoke the code I currently call prepare for not-yet-discovered callees internally and successfully materialize already with the first lookup("foo") above.

ormris added a subscriber: ormris.Aug 30 2018, 11:54 AM

You definitely want to do this as a real layer and materialization unit. It is beneficial even without lazy compilation, but the ability to compose it with laziness would be extra cool.

What aspect of the symbol flags gave you trouble? This is one of the most challenging parts of the new API, so I'm keen to hear where it is tripping people up so I can improve on it.

lhames added inline comments.Aug 30 2018, 12:30 PM
lib/ExecutionEngine/Orc/LLThinLTOJIT.cpp
154

There is no getSearchOrder() method as that would not be thread safe. You can use withSearchOrderDo:

auto &NewJD = // Get dylib to add to search order.
JD.withSearchOrderDo(
  [&](const JITDylibList &SearchOrder) {
    // Search to see if NewJD is already in the search order, bail out if it is.
    for (auto *E : SearchOrder)
      if (E == &NewJD)
        return;
    // NewJD was not in the search order. Add it.
    addToSearchOrder(NewJD);
  });

If this add-without-duplication operation turns out to be common we could add a DiscardDuplicates argument to addToSearchOrder and use that instead.

Not sure what's the best way to get rid of the binary object files. IIUC the ThinLTO tests are lit-based, so they build their summary-enhanced objects with clang and test via llvm-lto2 tool. Maybe I can turn all the unit tests into lit-test and add a hook to llvm-lto2? Don't know if there is a way to emit object files with summaries using yaml2obj or so? Any ideas?

You should check in LLVM textual IR files (.ll) instead of C++ source files or object files. Using clang -S -emit-llvm (or llvm-dis some-thinlto-bitcode-file.o) should get you started.

You should check in LLVM textual IR files (.ll) instead of C++ source files or object files. Using clang -S -emit-llvm (or llvm-dis some-thinlto-bitcode-file.o) should get you started.

Yes that would be great, but wouldn't it require IR representation for summaries? I didn't double-check myself, but there's a note in the language ref, "that temporarily the summary entries are skipped when parsing the assembly". Not sure if I understand that correctly, but I was under the impression that we can't have summaries in IR files yet.
https://llvm.org/docs/LangRef.html#thinlto-summary

You should check in LLVM textual IR files (.ll) instead of C++ source files or object files. Using clang -S -emit-llvm (or llvm-dis some-thinlto-bitcode-file.o) should get you started.

Yes that would be great, but wouldn't it require IR representation for summaries? I didn't double-check myself, but there's a note in the language ref, "that temporarily the summary entries are skipped when parsing the assembly". Not sure if I understand that correctly, but I was under the impression that we can't have summaries in IR files yet.
https://llvm.org/docs/LangRef.html#thinlto-summary

Looking at existing testcases in test/LTO, it seems like the existing practice is to check in a .ll file without a summary, and generate the summary using opt. Something like:

; RUN: opt -module-summary -o %t1.bc %s

That's probably better than my original suggestion anyway.

You should check in LLVM textual IR files (.ll) instead of C++ source files or object files. Using clang -S -emit-llvm (or llvm-dis some-thinlto-bitcode-file.o) should get you started.

Yes that would be great, but wouldn't it require IR representation for summaries? I didn't double-check myself, but there's a note in the language ref, "that temporarily the summary entries are skipped when parsing the assembly". Not sure if I understand that correctly, but I was under the impression that we can't have summaries in IR files yet.
https://llvm.org/docs/LangRef.html#thinlto-summary

This is stale - Sorry, I totally forgot to remove when I implemented the parsing side, which went in a couple months ago (r335602). For an example with a summary, see test/Assembler/thinlto-summary.ll. You need to use llvm-as to assembly it (not opt). Eventually other tools such as llvm-lto2 should be able to read assembly with summary directly, but I haven't had a chance to do that yet.

sgraenitz abandoned this revision.EditedSep 6 2018, 11:42 AM

Thanks for your input. For now I worked more on internals than on testing, but at least I managed to check in .ll files instead of .cpp and use .bc file in my tests:

clang -c -flto=thin -o Foo.o Foo.cpp
llvm-dis -o Foo.ll Foo.o
llvm-as -o Foo.bc Foo.ll

I will close this review in favour of https://reviews.llvm.org/D51744, where I use this approach.

lib/ExecutionEngine/Orc/LLThinLTOJIT.cpp
154

Sure right, I saw that earlier but didn't remember. Thanks!