| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 337637
|
|
|
|
| |
llvm-svn: 337626
|
|
|
|
|
|
|
|
| |
in preparation for"
Breaks the build with LLVM_ENABLE_THREADS=OFF.
llvm-svn: 337608
|
|
|
|
|
|
|
|
|
|
|
|
| |
deprecating SymbolResolver and AsynchronousSymbolQuery.
Both lookup overloads take a VSO search order to perform the lookup. The first
overload is non-blocking and takes OnResolved and OnReady callbacks. The second
is blocking, takes a boolean flag to indicate whether to wait until all symbols
are ready, and returns a SymbolMap. Both overloads take a RegisterDependencies
function to register symbol dependencies (if any) on the query.
llvm-svn: 337595
|
|
|
|
|
|
|
|
|
|
|
| |
This discards the unresolved symbols set and returns the flags map directly
(rather than mutating it via the first argument).
The unresolved symbols result made it easy to chain lookupFlags calls, but such
chaining should be rare to non-existant (especially now that symbol resolvers
are being deprecated) so the simpler method signature is preferable.
llvm-svn: 337594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A search order is a list of VSOs to be searched linearly to find symbols. Each
VSO now has a search order that will be used when fixing up definitions in that
VSO. Each VSO's search order defaults to just that VSO itself.
This is a first step towards removing symbol resolvers from ORC altogether. In
practice symbol resolvers tended to be used to implement a search order anyway,
sometimes with additional programatic generation of symbols. Now that VSOs
support programmatic generation of definitions via fallback generators, search
orders provide a cleaner way to achieve the desired effect (while removing a lot
of boilerplate).
llvm-svn: 337593
|
|
|
|
| |
llvm-svn: 336887
|
|
|
|
|
|
|
| |
This patch broke a few buildbots. I will investigate and re-apply when I have
a fix.
llvm-svn: 336767
|
|
|
|
|
|
| |
and fix a bug that these exposed.
llvm-svn: 336760
|
|
|
|
|
|
|
|
|
| |
symbols in another VSO).
Also fixes a bug where chained aliases within a single VSO would deadlock on
materialization.
llvm-svn: 336741
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
delegate method (and unit test).
The name 'replace' better captures what the old delegate method did: it
returned materialization responsibility for a set of symbols to the VSO.
The new delegate method delegates responsibility for a set of symbols to a new
MaterializationResponsibility instance. This can be used to split responsibility
between multiple threads, or multiple materialization methods.
llvm-svn: 336603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CompileOnDemandLayer.cpp uses function in these libraries, and builds
with `-DSHARED_LIB=ON` fail without this.
Reviewers: lhames
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D48995
llvm-svn: 336389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
writing them to a buffer and re-loading them.
Also introduces a multithreaded variant of SimpleCompiler
(MultiThreadedSimpleCompiler) for compiling IR concurrently on multiple
threads.
These changes are required to JIT IR on multiple threads correctly.
No test case yet. I will be looking at how to modify LLI / LLJIT to test
multithreaded JIT support soon.
llvm-svn: 336385
|
|
|
|
|
|
|
|
| |
The verifier identified several modules that were broken due to incorrect
linkage on declarations. To fix this, CompileOnDemandLayer2::extractFunction
has been updated to change decls to external linkage.
llvm-svn: 336150
|
|
|
|
|
|
| |
This should fix the recent builder failures in the test-global-ctors.ll testcase.
llvm-svn: 335680
|
|
|
|
| |
llvm-svn: 335677
|
|
|
|
| |
llvm-svn: 335673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLJIT is a prefabricated ORC based JIT class that is meant to be the go-to
replacement for MCJIT. Unlike OrcMCJITReplacement (which will continue to be
supported) it is not API or bug-for-bug compatible, but targets the same
use cases: Simple, non-lazy compilation and execution of LLVM IR.
LLLazyJIT extends LLJIT with support for function-at-a-time lazy compilation,
similar to what was provided by LLVM's original (now long deprecated) JIT APIs.
This commit also contains some simple utility classes (CtorDtorRunner2,
LocalCXXRuntimeOverrides2, JITTargetMachineBuilder) to support LLJIT and
LLLazyJIT.
Both of these classes are works in progress. Feedback from JIT clients is very
welcome!
llvm-svn: 335670
|
|
|
|
|
|
|
|
| |
AsynchronousSymbolQuery::canStillFail checks the value of the callback to
prevent sending it redundant error notifications, so we need to reset it after
running it.
llvm-svn: 335664
|
|
|
|
| |
llvm-svn: 335663
|
|
|
|
| |
llvm-svn: 335661
|
|
|
|
|
|
| |
symbolAliases can be used to define symbol aliases within a VSO.
llvm-svn: 335565
|
|
|
|
| |
llvm-svn: 335408
|
|
|
|
|
|
|
|
|
| |
CompileOnDemandLayer2 is a replacement for CompileOnDemandLayer built on the ORC
Core APIs. Functions in added modules are extracted and compiled lazily.
CompileOnDemandLayer2 supports multithreaded JIT'd code, and compilation on
multiple threads.
llvm-svn: 334967
|
|
|
|
|
|
|
|
|
|
|
|
| |
materializing weak symbols as strong.
This removes some elaborate flag tweaking and plays nicer with RuntimeDyld,
which relies of weak/common flags to determine whether it should emit a given
weak definition. (Switching to strong up-front makes it appear as if there is
already an overriding definition, which would require an extra back-channel to
override).
llvm-svn: 334966
|
|
|
|
| |
llvm-svn: 334918
|
|
|
|
|
|
|
|
| |
changes.
This guards against redundant notifications.
llvm-svn: 334916
|
|
|
|
| |
llvm-svn: 334911
|
|
|
|
| |
llvm-svn: 334910
|
|
|
|
|
|
|
|
|
|
|
| |
symbols in debug mode.
The MaterializationResponsibility class hijacks the Materializing flag to track
symbols that have not yet been resolved in order to guard against redundant
resolution. Since this is an API contract check and only enforced in debug mode
there is no reason to maintain the flag state in release mode.
llvm-svn: 334909
|
|
|
|
|
|
|
|
|
| |
Once a symbol has been selected for materialization it can no longer be
overridden. Stripping the weak flag guarantees this (override attempts will
then be treated as duplicate definitions and result in a DuplicateDefinition
error).
llvm-svn: 334771
|
|
|
|
| |
llvm-svn: 334724
|
|
|
|
| |
llvm-svn: 334723
|
|
|
|
|
|
|
|
|
|
|
| |
If WaitUntilReady is set to true then blockingLookup will return once all
requested symbols are ready. If WaitUntilReady is set to false then
blockingLookup will return as soon as all requested symbols have been
resolved. In the latter case, if any error occurs in finalizing the symbols it
will be reported to the ExecutionSession, rather than returned by
blockingLookup.
llvm-svn: 334722
|
|
|
|
|
|
| |
Finalized symbols are no longer in the materializing state.
llvm-svn: 334721
|
|
|
|
| |
llvm-svn: 334582
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a VSO has a fallback definition generator attached it will be called during
lookup (and lookupFlags) for any unresolved symbols. The definition generator
can add new definitions to the VSO for any unresolved symbol. This allows VSOs
to generate new definitions on demand.
The immediate use case for this code is supporting VSOs that can import
definitions found via dlsym on demand.
llvm-svn: 334538
|
|
|
|
|
|
|
| |
implement existing blocking lookups (the lookup function) and
JITSymbolResolverAdapter on top of that.
llvm-svn: 334537
|
|
|
|
|
|
|
|
|
|
| |
pre-existing SymbolFlags and SymbolToDefinition maps.
This constructor is useful when delegating work from an existing
IRMaterialiaztionUnit to a new one, as it avoids the cost of re-computing these
maps.
llvm-svn: 333852
|
|
|
|
|
|
|
|
|
|
|
| |
This method returns the set of symbols in the target VSO that have queries
waiting on them. This can be used to make decisions about which symbols to
delegate to another MaterializationUnit (typically this will involve
delegating all symbols that have *not* been requested to another
MaterializationUnit so that materialization of those symbols can be
deferred until they are requested).
llvm-svn: 333684
|
|
|
|
|
|
|
|
|
|
| |
and make it protected rather than private.
The new name reflects the actual information in the map, and this information
can be useful to derived classes (for example, to quickly look up the IR
definition of a requested symbol).
llvm-svn: 333683
|
|
|
|
| |
llvm-svn: 333492
|
|
|
|
|
|
|
|
|
| |
Previously JITCompileCallbackManager only supported single threaded code. This
patch embeds a VSO (see include/llvm/ExecutionEngine/Orc/Core.h) in the callback
manager. The VSO ensures that the compile callback is only executed once and that
the resulting address cached for use by subsequent re-entries.
llvm-svn: 333490
|
|
|
|
|
|
|
|
| |
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44890
llvm-svn: 333229
|
|
|
|
|
|
|
|
| |
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44890
llvm-svn: 333228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently RTDyldObjectLinkingLayer makes it hard to support
JITEventListeners. Which in turn means debugging and profiling JIT
generated code hard.
Supporting JITEventListeners at minimum requries a freed
callback (added).
As listeners expect the ObjectFile to be passed as well, an adaptor
between RTDyldObjectLinkingLayer and JITEventListeners would currently
need to also maintain ObjectFiles for all loaded modules. To make that
less awkward, extend the callbacks to pass the ObjectFile to both
Finalized and Freed callbacks. That requires extending the lifetime
of the object file when callbacks are present.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44890
llvm-svn: 333227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-appply r333147, reverted in r333152 due to a pre-existing bug. As
D47308 has been merged in r333206, the OSX issue should now be
resolved.
In many cases JIT users will know in which module a symbol
resides. Avoiding to search other modules can be more efficient. It
also allows to handle duplicate symbol names between modules.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44889
llvm-svn: 333215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lack of name mangling caused a unittest failure after r333147 (in
TestEagerIRCompilation), as OSX prefixes symbol names with '_'. The
lack of name mangling therefore leads to a NULL pointer being returned
and then called, hence the failure.
While it may look like it, this isn't an actual behavioral change, as
findSymbolIn() previously was not exposed externally, and essentially
dead code. Which explains why nobody noticed the issue previously.
Reviewers: lhames
Reviewed By: lhames
Subscribers: chandlerc, llvm-commits
Differential Revision: https://reviews.llvm.org/D47308
llvm-svn: 333206
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts r333147 until https://reviews.llvm.org/D47308 is ready to
be reviewed. r333147 exposed a behavioural difference between
OrcCBindingsStack::findSymbolIn() and OrcCBindingsStack::findSymbol(),
where only the latter does name mangling. After r333147 that causes a
test failure on OSX, because the new test looks for main using
findSymbolIn() but the mangled name is _main.
llvm-svn: 333152
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many cases JIT users will know in which module a symbol
resides. Avoiding to search other modules can be more efficient. It
also allows to handle duplicate symbol names between modules.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44889
llvm-svn: 333147
|