summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORC] Add a special 'main' JITDylib that is created on ExecutionSessionLang Hames2018-09-122-2/+12
| | | | | | | | | | | | | | | | | | | | | construction, a new convenience lookup method, and add-to layer methods. ExecutionSession now creates a special 'main' JITDylib upon construction. All subsequently created JITDylibs are added to the main JITDylib's search order by default (controlled by the AddToMainDylibSearchOrder parameter to ExecutionSession::createDylib). The main JITDylib's search order will be used in the future to properly handle cross-JITDylib weak symbols, with the first definition in this search order selected. This commit also adds a new ExecutionSession::lookup convenience method that performs a blocking lookup using the main JITDylib's search order, as this will be a very common operation for clients. Finally, new convenience overloads of IRLayer and ObjectLayer's add methods are introduced that add the given program representations to the main dylib, which is likely to be the common case. llvm-svn: 342086
* [ORC] Make RuntimeDyldObjectLinkingLayer2 take memory managers by unique_ptr.Lang Hames2018-09-061-185/+5
| | | | | | | | | | | | The existing memory manager API can not be shared between objects when linking concurrently (since there is no way to know which concurrent allocations were performed on behalf of which object, and hence which allocations would be safe to finalize when finalizeMemory is called). For now, we can work around this by requiring a new memory manager for each object. This change only affects the concurrent version of the ORC APIs. llvm-svn: 341579
* Remove some unnecessary constructor arguments.Lang Hames2018-09-052-8/+8
| | | | | | | ExecutionSession defaults to creating a new shared pool if none is provided, so explicitly passing one in is unnecessary. llvm-svn: 341494
* [ORC] Tidy up JITSymbolFlags to remove the need for some explicit static_casts.Lang Hames2018-09-022-6/+3
| | | | | | | | Removes the implicit conversion to the underlying type for JITSymbolFlags::FlagNames and replaces it with some bitwise and comparison operators. llvm-svn: 341282
* [ORC] Remove a stray debugging output line left in a unit test.Lang Hames2018-08-311-1/+0
| | | | llvm-svn: 341155
* [ORC] Add utilities to RTDyldObjectLinkingLayer2 to simplify symbol flagLang Hames2018-08-311-0/+123
| | | | | | | | | | | | | | | | | | | | | | | management and materialization responsibility registration. The setOverrideObjectFlagsWithResponsibilityFlags method instructs RTDyldObjectlinkingLayer2 to override the symbol flags produced by RuntimeDyld with the flags provided by the MaterializationResponsibility instance. This can be used to enable symbol visibility (hidden/exported) for COFF object files, which do not currently support the SF_Exported flag. The setAutoClaimResponsibilityForObjectSymbols method instructs RTDyldObjectLinkingLayer2 to claim responsibility for any symbols provided by a given object file that were not already in the MaterializationResponsibility instance. Setting this flag allows higher-level program representations (e.g. LLVM IR) to be added based on only a subset of the symbols they provide, without having to write intervening layers to scan and add the additional symbols. This trades diagnostic quality for convenience however: If all symbols are enumerated up-front then clashes can be detected and reported early. If this option is set, clashes for the additional symbols may not be detected until late, and detection may depend on the flow of control through JIT'd code. llvm-svn: 341154
* [ORC] Replace lookupFlags in JITSymbolResolver with getResponsibilitySet.Lang Hames2018-08-283-83/+88
| | | | | | | | | | | | | | The new method name/behavior more closely models the way it was being used. It also fixes an assertion that can occur when using the new ORC Core APIs, where flags alone don't necessarily provide enough context to decide whether the caller is responsible for materializing a given symbol (which was always the reason this API existed). The default implementation of getResponsibilitySet uses lookupFlags to determine responsibility as before, so existing JITSymbolResolvers should continue to work. llvm-svn: 340874
* [ORC] Add unit tests for the new RTDyldObjectLinkingLayer2 class.Lang Hames2018-08-272-0/+283
| | | | | | | The new unit tests match the old ones, which will remain in tree until the old RTDyldObjectLinkingLayer is removed. llvm-svn: 340786
* [ORC] Remove a workaround for systems lacking 8-byte atomics.Lang Hames2018-08-261-5/+0
| | | | | | | SymbolStringPool ref counts are now size_t, rather than uint64_t, so I do not think this is necessary any more. llvm-svn: 340704
* [ORC] Rename 'finalize' to 'emit' to avoid potential confusion.Lang Hames2018-08-181-18/+18
| | | | | | | | | | | | | | | An emitted symbol has had its contents written and its memory protections applied, but it is not automatically ready to execute. Prior to ORC supporting concurrent compilation, the term "finalized" could be interpreted two different (but effectively equivalent) ways: (1) The finalized symbol's contents have been written and its memory protections applied, and (2) the symbol is ready to run. Now that ORC supports concurrent compilation, sense (1) no longer implies sense (2). We have already introduced a new term, 'ready', to capture sense (2), so rename sense (1) to 'emitted' to avoid any lingering confusion. llvm-svn: 340115
* [ORC] Rename VSO to JITDylib.Lang Hames2018-08-173-101/+103
| | | | | | | | | | | | | VSO was a little close to VDSO (an acronym on Linux for Virtual Dynamic Shared Object) for comfort. It also risks giving the impression that instances of this class could be shared between ExecutionSessions, which they can not. JITDylib seems moderately less confusing, while still hinting at how this class is intended to be used, i.e. as a JIT-compiled stand-in for a dynamic library (code that would have been a dynamic library if you had wanted to compile it ahead of time). llvm-svn: 340084
* [ORC] Add a re-exports fallback definition generator.Lang Hames2018-08-021-0/+22
| | | | | | | | An instance of ReexportsFallbackDefinitionGenerator can be attached to a VSO (via setFallbackDefinitionGenerator) to re-export symbols on demandy from a backing VSO. llvm-svn: 338764
* [ORC] Add SerializationTraits for std::set and std::map.Lang Hames2018-07-301-37/+44
| | | | | | | | | | Also, make SerializationTraits for pairs forward the actual pair template type arguments to the underlying serializer. This allows, for example, std::pair<StringRef, bool> to be passed as an argument to an RPC call expecting a std::pair<std::string, bool>, since there is an underlying serializer from StringRef to std::string that can be used. llvm-svn: 338305
* [ORC] Re-apply r336760 with fixes.Lang Hames2018-07-211-6/+48
| | | | llvm-svn: 337637
* Re-apply r337595 with fix for LLVM_ENABLE_THREADS=Off.Lang Hames2018-07-202-182/+135
| | | | llvm-svn: 337626
* Revert r337595 "[ORC] Add new symbol lookup methods to ExecutionSessionBase ↵Reid Kleckner2018-07-202-135/+182
| | | | | | | | in preparation for" Breaks the build with LLVM_ENABLE_THREADS=OFF. llvm-svn: 337608
* [ORC] Add new symbol lookup methods to ExecutionSessionBase in preparation forLang Hames2018-07-202-182/+135
| | | | | | | | | | | | 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
* [ORC] Simplify VSO::lookupFlags to return the flags map.Lang Hames2018-07-203-32/+15
| | | | | | | | | | | 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
* [ORC] Replace SymbolResolvers in the new ORC layers with search orders on VSOs.Lang Hames2018-07-204-100/+109
| | | | | | | | | | | | | | | 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
* Revert r336760: "[ORC] Add unit tests for the reexports utility that were..."Lang Hames2018-07-111-42/+0
| | | | | | | This patch broke a few buildbots. I will investigate and re-apply when I have a fix. llvm-svn: 336767
* [ORC] Remove a shadowing definition.Lang Hames2018-07-111-2/+0
| | | | | | There is already a VSO member V in the CoreAPIsStandardTest test fixture. llvm-svn: 336761
* [ORC] Add unit tests for the reexports utility that were left out of r336741,Lang Hames2018-07-111-0/+42
| | | | | | and fix a bug that these exposed. llvm-svn: 336760
* [ORC] Drop constexpr in unit test to appease a bot.Lang Hames2018-07-111-4/+4
| | | | llvm-svn: 336758
* [ORC] Use a gtest fixture to remove a bunch of boilerplate in CoreAPIsTest.cpp.Lang Hames2018-07-111-299/+144
| | | | llvm-svn: 336757
* [ORC] Generalize alias materialization to support re-exports (i.e. aliasing ofLang Hames2018-07-101-1/+26
| | | | | | | | | symbols in another VSO). Also fixes a bug where chained aliases within a single VSO would deadlock on materialization. llvm-svn: 336741
* [ORC] Rename MaterializationResponsibility::delegate to replace and add a newLang Hames2018-07-091-2/+36
| | | | | | | | | | | | | 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
* [ORC] Add a symbolAliases function to the Core APIs.Lang Hames2018-06-261-0/+29
| | | | | | symbolAliases can be used to define symbol aliases within a VSO. llvm-svn: 335565
* [ORC] Only notify queries that they are resolved/ready when the query stateLang Hames2018-06-171-0/+54
| | | | | | | | changes. This guards against redundant notifications. llvm-svn: 334916
* [ORC] Erase empty dependence sets when adding new symbol dependencies.Lang Hames2018-06-171-0/+38
| | | | llvm-svn: 334910
* [ORC] Strip weak flags from a symbol once it is selected for materialization.Lang Hames2018-06-141-0/+47
| | | | | | | | | 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
* [ORC] Filter out self-dependencies in VSO::addDependencies.Lang Hames2018-06-141-0/+7
| | | | llvm-svn: 334724
* [ORC] Add a fallback definition generator for VSOs.Lang Hames2018-06-121-0/+27
| | | | | | | | | | | | 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
* [ORC] Use JITEvaluatedSymbol for IndirectStubsManager findStub and findPointer.Lang Hames2018-06-031-2/+2
| | | | | | | | Existing implementations of these methods do not require lazy materialization, and switching to JITEvaluatedSymbol allows us to remove error checking on the client side. llvm-svn: 333835
* [ORC] Add a getRequestedSymbols method to MaterializationResponsibility.Lang Hames2018-05-311-0/+56
| | | | | | | | | | | 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
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-302-3/+5
| | | | | | | | | 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
* [ORC] Add findSymbolIn() wrapper to C bindings, take #2.Andres Freund2018-05-241-6/+20
| | | | | | | | | | | | | | | | 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
* Revert r333147 "[ORC] Add findSymbolIn() wrapper to C bindings."Andres Freund2018-05-241-20/+6
| | | | | | | | | | | 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
* [ORC] Add findSymbolIn() wrapper to C bindings.Andres Freund2018-05-241-6/+20
| | | | | | | | | | | | 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
* [ORC] Remove the optional MaterializationResponsibility argument from lookup.Lang Hames2018-05-211-2/+2
| | | | | | | | The lookup function provides blocking symbol resolution for JIT clients (not layers themselves) so it does not need to track symbol dependencies via a MaterializationResponsibility. llvm-svn: 332897
* [ORC] Consolidate materialization errors, and generate them in VSO'sLang Hames2018-05-171-76/+19
| | | | | | | | | | | notifyFailed method rather than passing in an error generator. VSO::notifyFailed is responsible for notifying queries that they will not succeed due to error. In practice the queries don't care about the details of the failure, just the fact that a failure occurred for some symbols. Having VSO::notifyFailed take care of this simplifies the interface. llvm-svn: 332666
* [ORC] Rewrite the VSO symbol table yet again. Update related utilities.Lang Hames2018-05-163-211/+382
| | | | | | | | | | | | | | | | | | | VSOs now track dependencies for materializing symbols. Each symbol must have its dependencies registered with the VSO prior to finalization. Usually this will involve registering the dependencies returned in AsynchronousSymbolQuery::ResolutionResults for queries made while linking the symbols being materialized. Queries against symbols are notified that a symbol is ready once it and all of its transitive dependencies are finalized, allowing compilation work to be broken up and moved between threads without queries returning until their symbols fully safe to access / execute. Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are updated to support dependence tracking and more explicitly track responsibility for symbols from the point of definition until they are finalized. llvm-svn: 332541
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [ORC] Add a MaterializationResponsibility class to track responsibility forLang Hames2018-04-162-53/+44
| | | | | | | | | | | | | | | | | materializing function definitions. MaterializationUnit instances are responsible for resolving and finalizing symbol definitions when their materialize method is called. By contract, the MaterializationUnit must materialize all definitions it is responsible for and no others. If it can not materialize all definitions (because of some error) then it must notify the associated VSO about each definition that could not be materialized. The MaterializationResponsibility class tracks this responsibility, asserting that all required symbols are resolved and finalized, and that no extraneous symbols are resolved or finalized. In the event of an error it provides a convenience method for notifying the VSO about each definition that could not be materialized. llvm-svn: 330142
* [ORC] Merge VSO notifyResolutionFailed and notifyFinalizationFailed in toLang Hames2018-04-161-2/+2
| | | | | | | | | notifyMaterializationFailed. The notifyMaterializationFailed method can determine which error to raise by looking at which queue the pending queries are in (resolution or finalization). llvm-svn: 330141
* [ORC] Plumb error notifications through the VSO interface.Lang Hames2018-04-121-6/+167
| | | | | | | This allows materializers to notify the VSO that they were unable to resolve or finalize symbols. llvm-svn: 329934
* [ORC] Create a new SymbolStringPool by default in ExecutionSession constructor.Lang Hames2018-04-025-22/+12
| | | | | | This makes the common case of constructing an ExecutionSession tidier. llvm-svn: 329013
* [ORC] Restore the narrower check from before r328687.Lang Hames2018-03-281-1/+2
| | | | | | | This should get the builders green again while I investigate why r328706 was insufficient. llvm-svn: 328711
* [ORC] Re-add the Windows check that was dropped in r328687.Lang Hames2018-03-281-0/+4
| | | | | | | | | This check prevents the ORC execution tests from running on Windows (which is not supported yet). This should fix the windows bots. llvm-svn: 328706
* [ORC] Fix ORC on platforms without indirection support.Lang Hames2018-03-283-9/+16
| | | | | | | | | | Previously this crashed because a nullptr (returned by createLocalIndirectStubsManagerBuilder() on platforms without indirection support) functor was unconditionally invoked. Patch by Andres Freund. Thanks Andres! llvm-svn: 328687
* [ORC] Join materialization thread in unit testBenjamin Kramer2018-03-231-5/+6
| | | | | | | | There's are race between this thread and the destructor of the test ORC components on the main threads. I saw flaky failures there in about 4% of the runs of this unit test. llvm-svn: 328300
OpenPOWER on IntegriCloud