Update llvm-exegesis to use OrcJIT instead of MCJIT

[RKSimon]

Bugzilla Link	42419
Version	trunk
OS	Windows NT
CC	@legrosbuffle,@dwblaikie,@gchatelet,@LebedevRI,@lhames

Extended Description

llvm-exegesis really should be using OrcJIT.

MCJIT is showing its age and OrcJIT is the main focus of development these days.

[gchatelet]

Thx for the heads up!

Is it really battle tested though? The unittests seems to be failing for months now, check-llvm reports:

Failing Tests (34):
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.AddAndMaterializeLazySymbol
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.BasicSuccessfulLookup
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.DefineMaterializingSymbol
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.EmptyLookup
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.FailEmissionEarly
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.FailResolution
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.GeneratorTest
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.LookupWithGeneratorFailure
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.LookupWithHiddenSymbols
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.RemoveSymbolsTest
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestBasicAliases
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestBasicReExports
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestBasicWeakSymbolMaterialization
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestChainedAliases
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestCircularDependenceInOneJITDylib
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestGetRequestedSymbolsAndReplace
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestLookupWithThreadedMaterialization
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestLookupWithUnthreadedMaterialization
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestMaterializationResponsibilityDelegation
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestMaterializeWeakSymbol
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestReexportsGenerator
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestThatReExportsDontUnnecessarilyMaterialize
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.TestTrivialCircularDependency
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/LazyReexportsTest.BasicLocalCallThroughManagerOperation
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/LegacyRTDyldObjectLinkingLayerExecutionTest.NoDuplicateFinalization
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/OrcCAPIExecutionTest.TestAddObjectFile
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/OrcCAPIExecutionTest.TestDirectCallbacksAPI
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/OrcCAPIExecutionTest.TestEagerIRCompilation
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/OrcCAPIExecutionTest.TestLazyIRCompilation
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/RTDyldObjectLinkingLayerTest.TestAutoClaimResponsibilityForSymbols
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/RTDyldObjectLinkingLayerTest.TestOverrideObjectFlags
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/RTDyldObjectLinkingLayerTest.TestSetProcessAllSections
LLVM :: ExecutionEngine/JITLink/X86/MachO_x86-64_ehframe.test
LLVM :: ExecutionEngine/JITLink/X86/MachO_x86-64_relocations.s

Expected Passes : 31209
Expected Failures : 151
Unsupported Tests : 661
Unexpected Failures: 34

[lhames]

Hi Guillaume,

Where are you seeing those failures? I have not seen them on my local build.

-- Lang.

[gchatelet]

Here is a reproducer

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DLLVM_ENABLE_PROJECTS=clang -DLLVM_BUILD_DOCS=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DBUILD_SHARED_LIBS=ON -DLLVM_USE_SPLIT_DWARF=ON -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_TARGETS_TO_BUILD=all -DLLVM_EXEGESIS_TARGETS=X86 -DLLVM_ENABLE_WERROR=ON -Wno-dev -H. -B/tmp/clang_build_debug_clang -GNinja
ninja -C /tmp/clang_build_debug_clang check-llvm

The output is available here:
https://pastebin.com/ySd1AxGf

[lhames]

I can't reproduce your setup exactly (I'm on Darwin), but I've gotten as close as I can and still don't see those failures. I don't think they're occurring on the bots either.

Would you mind checking this out under a debugger? The assertion is for a null query object being passed in to JITDylib::lodgeQuery (lib/ExecutionEngine/Orc/Core.cpp) from JITDylib::lookup. The allocation of the object in JITDylib::lookup seems correct to me:

// QUERY ALLOCATED HERE.
auto Q = std::make_shared(Unresolved, RequiredState,
std::move(NotifyComplete));
bool QueryComplete = false;

// QUERY CAPTURED BY REFERENCE HERE
auto LodgingErr = runSessionLocked(& -> Error {
// QUERY CAPTURED BY REFERENCE HERE
auto LodgeQuery = & -> Error {
for (auto &KV : SearchOrder) {
assert(KV.first && "JITDylibList entries must not be null");
assert(!CollectedMUsMap.count(KV.first) &&
"JITDylibList should not contain duplicate entries");

    auto &JD = *KV.first;
    auto MatchNonExported = KV.second;
    // 
    if (auto Err = JD.lodgeQuery(Q, Unresolved, MatchNonExported,
                                 CollectedMUsMap[&JD]))
      return Err;
  }

  if (!Unresolved.empty())
    return make_error<SymbolsNotFound>(std::move(Unresolved));

  return Error::success();
};

// INNNER LAMBDA EXECUTED HERE.
if (auto Err = LodgeQuery()) {
  // Query failed.

...

The nested capture by reference should be safe, but is unusual. Is it possible you're hitting a miscompile? What compiler version are you using?

[gchatelet]

Indeed I've a pretty old clang version
clang version 4.0.1-10 (tags/RELEASE_401/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

It's the default one for my distro, I'll make sure to update it.

[RKSimon]

Candidate Patch by @boomanaiden154 #72838