Re-apply "[ORC] Track all dependencies on symbols that aren't..." with fixes.

This reapplies 427fb5cc5ac, which was reverted in 08c1a6b3e18 due to bot
failures.

The fix was to remove an incorrect a

Re-apply "[ORC] Track all dependencies on symbols that aren't..." with fixes.

This reapplies 427fb5cc5ac, which was reverted in 08c1a6b3e18 due to bot
failures.

The fix was to remove an incorrect assertion: In IL_emit, during the initial
worklist loop, an EDU can have all of its dependencies removed without becoming
ready (because it may still have implicit dependencies that will be added back
during the subsequent propagateExtraEmitDeps operation). The EDU will be marked
Ready at the end of IL_emit if its Dependencies set is empty at that point.
Prior to that we can only assert that it's either Emitted or Ready (which is
already covered by other assertions).

show more ...

Revert "[ORC] Track all dependencies on symbols that aren't Ready yet."

This reverts commit 427fb5cc5ac34414c4682c90d3db0c63c5a1b227 while I investigate
the bot failure in https://lab.llvm.org/build

Revert "[ORC] Track all dependencies on symbols that aren't Ready yet."

This reverts commit 427fb5cc5ac34414c4682c90d3db0c63c5a1b227 while I investigate
the bot failure in https://lab.llvm.org/buildbot/#/builders/95/builds/6835.

show more ...

[ORC] Track all dependencies on symbols that aren't Ready yet.

AsynchronousSymbolQuery tracks the symbols that it depends on in order to (1)
detach the query in the event of a failure, and (2) repor

[ORC] Track all dependencies on symbols that aren't Ready yet.

AsynchronousSymbolQuery tracks the symbols that it depends on in order to (1)
detach the query in the event of a failure, and (2) report those dependencies
to clients of the ExecutionSession::lookup method (via the RegisterDependencies
argument). Previously we tracked only dependencies on symbols that didn't meet
the required state (the only symbols that the query needs to be attached to),
but this is insufficient to report all necessary dependencies to lookup clients.
E.g. A lookup requiring SymbolState::Resolved where some matched symbol is
already Resolved but not yet Emitted or Ready would result in the dependency on
that symbol not being reported, which could result in illegal access in
concurrent JIT setups. (This bug was discovered by @mikaoP on discord with a
simple concurrent JIT setup).

This patch tracks and reports all dependencies on symbols that aren't Ready yet,
correcting the under-reporting issue. AsynchronousSymbolQuery::detach is updated
to stop asserting that all depended-upon symbols have a query attached.

show more ...

[ORC] Move absoluteSymbols from Core.h to new AbsoluteSymbols.h header. NFC.

Continuing Core.h clean-up.

If you see any errors about a missing absoluteSymbols function you need to
include the new A

[ORC] Move absoluteSymbols from Core.h to new AbsoluteSymbols.h header. NFC.

Continuing Core.h clean-up.

If you see any errors about a missing absoluteSymbols function you need to
include the new AbsoluteSymbols.h header.

show more ...

[ORC] Switch ExecutionSession::ErrorReporter to use unique_function.

This allows the ReportError functor to hold move-only types.

[Orc] Fix `-Wsign-compare` warnings in unittest

Multiple compares against `LookupsCompleted`, which is effectively an
unsigned long, with constant signed integer were throwing -Wsign-compare
warning

[Orc] Fix `-Wsign-compare` warnings in unittest

Multiple compares against `LookupsCompleted`, which is effectively an
unsigned long, with constant signed integer were throwing -Wsign-compare
warnings.

This is effectively NFC.

show more ...

[ORC] Add tests for error handling paths in suspended generators.

Test that (1) errors returned from a manually suspended generator are
propagated as expected, and (2) automatic suspension does not

[ORC] Add tests for error handling paths in suspended generators.

Test that (1) errors returned from a manually suspended generator are
propagated as expected, and (2) automatic suspension does not interfere with
our ability to resume (and return errors from) a generator.

show more ...

Re-apply "[ORC] Unify task dispatch across ExecutionSession..." with more fixes.

This re-applies 6094b3b7db7, which was reverted in e7efd37c229 (and before that
in 1effa19de24) due to bot failures.

Re-apply "[ORC] Unify task dispatch across ExecutionSession..." with more fixes.

This re-applies 6094b3b7db7, which was reverted in e7efd37c229 (and before that
in 1effa19de24) due to bot failures.

The test failures were fixed by having SelfExecutorProcessControl use an
InPlaceTaskDispatcher by default, rather than a DynamicThreadPoolTaskDispatcher.
This shouldn't be necessary (and indicates a concurrency issue elsewhere), but
InPlaceTaskDispatcher is a less surprising default, and better matches the
existing behavior (compilation on current thread by default), so the change
seems reasonable. I've filed https://github.com/llvm/llvm-project/issues/89870
to investigate the concurrency issue as a follow-up.

Coding my way home: 6.25133S 127.94177W

show more ...

Revert "Re-apply [ORC] Unify task dispatch across ExecutionSession and..."

This reverts commit 1effa19de24 while I investigate the test failure at
https://lab.llvm.org/buildbot/#/builders/285/builds

Revert "Re-apply [ORC] Unify task dispatch across ExecutionSession and..."

This reverts commit 1effa19de24 while I investigate the test failure at
https://lab.llvm.org/buildbot/#/builders/285/builds/888.

show more ...

Re-apply "[ORC] Unify task dispatch across ExecutionSession and..." with fix.

This re-applies 6094b3b7db7, which was reverted in a28557aadd8 due to broken
bots. As far as I can tell all failures wer

Re-apply "[ORC] Unify task dispatch across ExecutionSession and..." with fix.

This re-applies 6094b3b7db7, which was reverted in a28557aadd8 due to broken
bots. As far as I can tell all failures were due to a missing #include <deque>,
which has been adedd in this commit.

show more ...

Revert "[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl."

This reverts commit 6094b3b7db7eab8318b9d30dec2691d231c7bdff.

Multiple bots are broken.

[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl.

Updates ExecutionSession to use the ExecutorProcessControl object's
TaskDispatcher rather than having a separate dispatc

[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl.

Updates ExecutionSession to use the ExecutorProcessControl object's
TaskDispatcher rather than having a separate dispatch function. This gives the
TaskDispatcher a global view of all tasks to be executed, and provides a
single point to wait on for tasks to complete when shutting down the JIT.

show more ...

[ORC] Merge MaterializationResponsibility notifyEmitted and addDependencies

Removes the MaterializationResponsibility::addDependencies and
addDependenciesForAll methods, and transfers dependency re

[ORC] Merge MaterializationResponsibility notifyEmitted and addDependencies

Removes the MaterializationResponsibility::addDependencies and
addDependenciesForAll methods, and transfers dependency registration to
the notifyEmitted operation. The new dependency registration allows
dependencies to be specified for arbitrary subsets of the
MaterializationResponsibility's symbols (rather than just single symbols
or all symbols) via an array of SymbolDependenceGroups (pairs of symbol
sets and corresponding dependencies for that set).

This patch aims to both improve emission performance and simplify
dependence tracking. By eliminating some states (e.g. symbols having
registered dependencies but not yet being resolved or emitted) we make
some errors impossible by construction, and reduce the number of error
cases that we need to check. NonOwningSymbolStringPtrs are used for
dependence tracking under the session lock, which should reduce
ref-counting operations, and intra-emit dependencies are resolved
outside the session lock, which should provide better performance when
JITing concurrently (since some dependence tracking can happen in
parallel).

The Orc C API is updated to account for this change, with the
LLVMOrcMaterializationResponsibilityNotifyEmitted API being modified and
the LLVMOrcMaterializationResponsibilityAddDependencies and
LLVMOrcMaterializationResponsibilityAddDependenciesForAll operations
being removed.

show more ...

[OrcJITTests] Fix warning: suggest explicit braces to avoid ambiguous 'else' (NFC)

Likely related to platform-specific expansion of gtest macros:
```
llvm/unittests/ExecutionEngine/Orc/CoreAPIsTest.

[OrcJITTests] Fix warning: suggest explicit braces to avoid ambiguous 'else' (NFC)

Likely related to platform-specific expansion of gtest macros:
```
llvm/unittests/ExecutionEngine/Orc/CoreAPIsTest.cpp:1276:12: warning: suggest explicit
braces to avoid ambiguous 'else' [-Wdangling-else]
```

show more ...

[ORC] Automatically suspend and resume lookups that depend on in-use generators.

Access to individual DefinitionGenerators is serialized in order to make
generators easier to implement: serializing

[ORC] Automatically suspend and resume lookups that depend on in-use generators.

Access to individual DefinitionGenerators is serialized in order to make
generators easier to implement: serializing access means that tryToGenerate
methods don't have to handle concurrent, potentially overlapping, requests.

Prior to this patch serialization was achieved by having each lookup acquire a
lock on each generator, however this causes the lookup thread to block if the
generator is in use. In the common case where many objects reference some
common library symbol that is provided by a generator this may cause many
threads to block concurrently preventing progress on other work.

This patch changes the model so that lookups are automatically suspended if
they need to use a generator that is already in use, and then automatically
resumed once the generator is free. This is achieved by reusing the lookup
suspension machinery that was introduced in 069919c9ba3 for optionally
asynchronous generators.

show more ...

[ORC] In defineMaterializing, error out early if tracker is defunct.

An in-flight materialization may try to claim responsibility for new symbols
(via MaterializationResponsibility::defineMaterializ

[ORC] In defineMaterializing, error out early if tracker is defunct.

An in-flight materialization may try to claim responsibility for new symbols
(via MaterializationResponsibility::defineMaterializing) after the tracker that
is associated with the materialization is removed, leaving the tracker defunct.

Failure to error out early here could leave the JITDylib in an invalid state,
with defineMaterializing associating new symbols with the already-defunct
tracker. Erroring out early prevents this.

show more ...

[ORC] Add a JITDylib::addToLinkOrder convenience method.

This appends the given JITDylibSearchOrder to the JITDylib's existing one.

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in this patch as a
replacement for JITEvaluatedSymbol: ExecutorSymbolDef is an (ExecutorAddr,
JITSymbolFlags) pair, where JITEvaluatedSymbol was a (JITTargetAddress,
JITSymbolFlags) pair.

A number of APIs had already migrated from JITTargetAddress to ExecutorAddr,
but many of ORC's internals were still using the older type. This patch aims
to address that.

Some public APIs are affected as well. If you need to migrate your APIs you can
use the following operations:

* ExecutorAddr::toPtr replaces jitTargetAddressToPointer and
jitTargetAddressToFunction.

* ExecutorAddr::fromPtr replace pointerToJITTargetAddress.

* ExecutorAddr(JITTargetAddress) creates an ExecutorAddr value from a
JITTargetAddress.

* ExecutorAddr::getValue() creates a JITTargetAddress value from an
ExecutorAddr.

JITTargetAddress and JITEvaluatedSymbol will remain in JITSymbol.h for now, but
the aim will be to eventually deprecate and remove these types (probably when
MCJIT and RuntimeDyld are deprecated).

show more ...

[llvm] Use std::optional instead of Optional

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-ge

[llvm] Use std::optional instead of Optional

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[ORC] Add a unit test to verify that bound weak symbols can't be overridden.

Weak symbols can be overridden while they're in the NeverSearched state, but
should not be able to be overridden once the

[ORC] Add a unit test to verify that bound weak symbols can't be overridden.

Weak symbols can be overridden while they're in the NeverSearched state, but
should not be able to be overridden once they've been bound by some lookup.
Historically we guaranteed this by stripping the weak flag once a symbol as
bound, causing it to appear as if it were strong. In ffe2dda29f3 we changed
that behavior to retain weak flags on symbols (to facilitate tracking for
dynamic re-binding during dlopen). This test checks that we still fail as
required after ffe2dda29f3.

show more ...

[ORC] Reset MaterializationUnit::InitSymbol if the init symbol is discarded.

Discarding the init symbol is expected to be uncommon (it represents metadata
in the MaterializationUnit that is relevant

[ORC] Reset MaterializationUnit::InitSymbol if the init symbol is discarded.

Discarding the init symbol is expected to be uncommon (it represents metadata
in the MaterializationUnit that is relevant to dlopen, and this will not
usually be fully duplicated in some other location), however if a client has
marked an InitSymbol as weak and it is selected to be discarded then we should
keep the data structure consistent.

show more ...

[ORC] Allow FailedToMaterialize errors to outlive ExecutionSessions.

Idiomatic llvm::Error usage can result in a FailedToMaterialize error tearing
down an ExecutionSession instance. Since the Failed

[ORC] Allow FailedToMaterialize errors to outlive ExecutionSessions.

Idiomatic llvm::Error usage can result in a FailedToMaterialize error tearing
down an ExecutionSession instance. Since the FailedToMaterialize error holds
SymbolStringPtrs and JITDylib references this leads to crashes when accessing
or logging the error.

This patch modifies FailedToMaterialize to retain the SymbolStringPool and
JITDylibs involved in the failure so that we can safely report an error message
to the client, even if the error tears down the session.

The contract for JITDylibs allows the getName method to be used even after the
session has been torn down, but no other JITDylib fields should be accessed via
the FailedToMaterialize error if the ssesion has been torn down. Logging the
error is guaranteed to be safe in all cases.

show more ...

[ORC] Add a ~ExectionSession destructor to verify that endSession was called.

Clients are required to call ExecutionSession::endSession before destroying the
ExecutionSession. Failure to do so can l

[ORC] Add a ~ExectionSession destructor to verify that endSession was called.

Clients are required to call ExecutionSession::endSession before destroying the
ExecutionSession. Failure to do so can lead to memory leaks and other difficult
to debug issues. Enforcing this requirement by assertion makes it easy to spot
or debug situations where the contract was not followed.

show more ...

[ORC] Allow JITDylib::getDFSLinkOrder and friends to fail for defunct JITDylibs.

Calls to JITDylib's getDFSLinkOrder and getReverseDFSLinkOrder methods (both
static an non-static versions) are now v

[ORC] Allow JITDylib::getDFSLinkOrder and friends to fail for defunct JITDylibs.

Calls to JITDylib's getDFSLinkOrder and getReverseDFSLinkOrder methods (both
static an non-static versions) are now valid to make on defunct JITDylibs, but
will return an error if any JITDylib in the link order is defunct.

This means that platforms can safely lookup link orders by name in response to
jit-dlopen calls from the ORC runtime, even if the call names a defunct
JITDylib -- the call will just fail with an error.

show more ...

[ORC] Fix ambiguous call to overloaded function.

This should fix the build failure at
https://lab.llvm.org/buildbot#builders/110/builds/8359