summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORC] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames2018-02-064-57/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular this patch switches RTDyldObjectLinkingLayer to use orc::SymbolResolver and threads the requried changse (ExecutionSession references and VModuleKeys) through the existing layer APIs. The purpose of the new resolver interface is to improve query performance and better support parallelism, both in JIT'd code and within the compiler itself. The most visibile change is switch of the <Layer>::addModule signatures from: Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod, std::shared_ptr<JITSymbolResolver> Resolver) to: Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod); Typical usage of addModule will now look like: auto K = ES.allocateVModuleKey(); Resolvers[K] = createSymbolResolver(...); Layer.addModule(K, std::move(Mod)); See the BuildingAJIT tutorial code for example usage. llvm-svn: 324405
* [ORC] Rename NullResolver to NullLegacyResolver.Lang Hames2018-02-033-14/+14
| | | | | | | | | This resolver conforms to the LegacyJITSymbolResolver interface, and will be replaced with a null-returning resolver conforming to the newer orc::SymbolResolver interface in the near future. This patch renames the class to avoid a clash. llvm-svn: 324175
* [ORC] Refactor the various lookupFlags methods to return the flags map via theLang Hames2018-01-252-38/+41
| | | | | | | | | | | | first argument. This makes lookupFlags more consistent with lookup (which takes the query as the first argument) and composes better in practice, since lookups are usually linearly chained: Each lookupFlags can populate the result map based on the symbols not found in the previous lookup. (If the maps were returned rather than passed by reference there would have to be a merge step at the end). llvm-svn: 323398
* [ORC] Add helpers for building orc::SymbolResolvers from legacy findSymbol-styleLang Hames2018-01-241-0/+73
| | | | | | | | | | | | | | | | | | | | | functions/methods that return JITSymbols. lookupFlagsWithLegacyFn takes a SymbolNameSet and a legacy lookup function and returns a LookupFlagsResult. It uses the legacy lookup function to search for each symbol. If found, getFlags is called on the symbol and the flags added to the SymbolFlags map. If not found, the symbol is added to the SymbolsNotFound set. lookupWithLegacyFn takes an AsynchronousSymbolQuery, a SymbolNameSet and a legacy lookup function. Each symbol in the SymbolNameSet is searched for via the legacy lookup function. If it is found, its getAddress function is called (triggering materialization if it has not happened already) and the resulting mapping stored in the query. If it is not found the symbol is added to the unresolved symbols set which is returned at the end of the function. If an error occurs during legacy lookup or materialization it is passed to the query via setFailed and the function returns immediately. llvm-svn: 323388
* [ORC] Add a LambdaSymbolResolver convenience class and docs for SymbolResolver.Lang Hames2018-01-241-0/+66
| | | | | | | | | | | | | | | This patch adds a LambdaSymbolResolver convenience utility that can create an orc::SymbolResolver from a pair of function objects that supply the behavior for the lookupFlags and lookup methods. This class plays the same role for orc::SymbolResolver as the legacy LambdaResolver class plays for LegacyJITSymbolResolver, and will replace the latter class once all ORC APIs are migrated to orc::SymbolResolver. This patch also adds some documentation for the orc::SymbolResolver class as this was left out of the original commit. llvm-svn: 323375
* [ORC] Add orc::SymbolResolver, a Orc/Legacy API interop header, and anLang Hames2018-01-222-0/+91
| | | | | | | | | | | | | | | orc::SymbolResolver to JITSymbolResolver adapter. The new orc::SymbolResolver interface uses asynchronous queries for better performance. (Asynchronous queries with bulk lookup minimize RPC/IPC overhead, support parallel incoming queries, and expose more available work for distribution). Existing ORC layers will soon be updated to use the orc::SymbolResolver API rather than the legacy llvm::JITSymbolResolver API. Because RuntimeDyld still uses JITSymbolResolver, this patch also includes an adapter that wraps an orc::SymbolResolver with a JITSymbolResolver API. llvm-svn: 323073
* [ORC] Add a lookupFlags method to VSO.Lang Hames2018-01-211-0/+50
| | | | | | | | | | | | lookupFlags returns a SymbolFlagsMap for the requested symbols, along with a set containing the SymbolStringPtr for any symbol not found in the VSO. The JITSymbolFlags for each symbol will have been stripped of its transient JIT-state flags (i.e. NotMaterialized, Materializing). Calling lookupFlags does not trigger symbol materialization. llvm-svn: 323060
* [ORC] Re-apply r321838 again with a workaround for a bug present in the libcxxLang Hames2018-01-102-0/+212
| | | | | | | | | | | | | version being used on some of the green dragon builders (plus a clang-format). Workaround: AsynchronousSymbolQuery and VSO want to work with JITEvaluatedSymbols anyway, so just use them (instead of JITSymbol, which happens to tickle the bug). The libcxx bug being worked around was fixed in r276003, and there are plans to update the offending builders. llvm-svn: 322140
* [ORC] Remove AsynchronousSymbolQuery while I debug an issue on one of theLang Hames2018-01-062-58/+0
| | | | | | builders. llvm-svn: 321941
* [ORC] More debugging output to track down tester failures.Lang Hames2018-01-061-0/+6
| | | | llvm-svn: 321925
* [ORC] Temporarily adding some redundant asserts / debug output to aid inLang Hames2018-01-061-0/+1
| | | | | | debugging a tester failure. llvm-svn: 321920
* [ORC] Fix a think-o in the current AsynchronousSymbolQuery test.Lang Hames2018-01-061-1/+1
| | | | | | | This *should* be a no-op as far as the current failure is concerned, but needs to be fixed anyway. llvm-svn: 321919
* [ORC] Re-apply just the AsynchronousSymbolLookup class from r321838 while ILang Hames2018-01-052-0/+51
| | | | | | investigate builder / test failures. llvm-svn: 321910
* [ORC] Re-revert r321838: Tests are still failing.Lang Hames2018-01-052-227/+0
| | | | llvm-svn: 321858
* [ORC] Re-apply r321838 - Addition of new ORC core APIs.Lang Hames2018-01-052-0/+227
| | | | | | | | The original commit broke the builders due to a think-o in an assertion: AsynchronousSymbolQuery's constructor needs to check the callback member variables, not the constructor arguments. llvm-svn: 321853
* Revert r321838 -- It broke some of the builders.Lang Hames2018-01-052-227/+0
| | | | llvm-svn: 321842
* [ORC] Add new core ORC APIs (Core.h/Core.cpp): VSO, AsynchronousSymbolQuery andLang Hames2018-01-052-0/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SymbolSource. These new APIs are a first stab at tackling some current shortcomings of ORC, especially in performance and threading support. VSO (Virtual Shared Object) is a symbol table representing the symbol definitions of a set of modules that behave as if they had been statically linked together into a shared object or dylib. Symbol definitions, either pre-defined addresses or lazy definitions, can be added and queries for symbol addresses made. The table applies the same linkage strength rules that static linkers do when constructing a dylib or shared object: duplicate definitions result in errors, strong definitions override weak or common ones. This class should improve symbol lookup speed by providing centralized symbol tables (as compared to the findSymbol implementation in the in-tree ORC layers, which maintain one symbol table per object file / module added). AsynchronousSymbolQuery is a query for the addresses of a set of symbols. Query results are returned via a callback once they become available. Querying for a set of symbols, rather than one symbol at a time (as the current lookup scheme does) the JIT has the opportunity to make better use of available resources (e.g. by spawning multiple jobs to materialize the requested symbols if possible). Returning results via a callback makes queries asynchronous, so queries from multiple threads of JIT'd code can proceed simultaneously. SymbolSource represents a source of symbol definitions. It is used when adding lazy symbol definitions to a VSO. Symbol definitions can be materialized when needed or discarded if a stronger definition is found. Materializing on demand via SymbolSources should (eventually) allow us to remove the lazy materializers from JITSymbol, which will in turn allow the removal of many current error checks and reduce the number of RPC round-trips involved in materializing remote symbols. Adding a discard function allows sources to discard symbol definitions (or mark them as available_externally), reducing the amount of redundant code generated by the JIT for ODR symbols. llvm-svn: 321838
* [ORC] Add dereference operator to SymbolStringPtr.Lang Hames2018-01-051-0/+6
| | | | | | Dereference yields a StringRef. llvm-svn: 321836
* [orc][cmake] Check if 8 byte atomics require libatomic for unittestSimon Dardis2017-12-201-1/+6
| | | | | | | | | | | | | rL319838 introduced SymbolStringPool which uses 8 byte atomics for reference counters. On systems which do not support such atomics natively such as MIPS32, explicitly add libatomic as one of the libraries for SymbolStringPool's unittest. Reviewers: lhames, beanz Differential Revision: https://reviews.llvm.org/D41010 llvm-svn: 321225
* Remove redundant includes from unittests.Michael Zolotukhin2017-12-132-2/+0
| | | | llvm-svn: 320630
* [ORC] Mark SymbolStringPool methods as inline to avoid linkage errors, add aLang Hames2017-12-071-1/+6
| | | | | | less-than comparison to SymbolStringPtr and a corresponding unit test. llvm-svn: 320116
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [Orc] Add a SymbolStringPool data structure for efficient storage and fastLang Hames2017-12-052-0/+44
| | | | | | | | | comparison of symbol names. SymbolStringPool is a thread-safe string pool that will be used in upcoming Orc APIs to facilitate efficient storage and fast comparison of symbol name strings. llvm-svn: 319839
* [ORC] Replace decltype with a concrete type to make MSVC happy.Lang Hames2017-09-291-2/+2
| | | | | | This should fix some build failures on windows bots due to r314486. llvm-svn: 314490
* Fix -Werror build.Evgeniy Stepanov2017-09-281-5/+5
| | | | | | | /code/llvm-project/llvm/unittests/ExecutionEngine/Orc/RTDyldObjectLinkingLayerTest.cpp:260:38: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture] [this](decltype(ObjLayer)::ObjHandleT, llvm-svn: 314454
* [ORC] Fix the type of RTDyldObjectLinkingLayer::NotifyLoadedFtor.Lang Hames2017-09-281-0/+8
| | | | | | Bug found by Stefan Granitz. Thanks Stefan! llvm-svn: 314436
* [ORC] Update the GlobalMappingLayer interface to fit the error-ized layerLang Hames2017-09-283-73/+66
| | | | | | | | | concept. Add a unit-test to make sure we don't backslide, and tweak the MockBaseLayer utility to make it easier to test this kind of thing in the future. llvm-svn: 314374
* [ORC] Hook up the LLVMOrcAddObjectFile function in the Orc C Bindings.Lang Hames2017-09-171-0/+40
| | | | | | This can be used to add a relocatable object to the JIT session. llvm-svn: 313474
* [ORC] Add ErrorSuccess and void specializations to AsyncHandlerTraits.Lang Hames2017-09-071-0/+45
| | | | | | | | | | This will allow async handlers to be added that return void or Error::success(). Such handlers are expected to be common, since one of the primary uses of addAsyncHandler is to run the body of the handler in a detached thread, in which case the main handler returns immediately and does not need to provide an Error value. llvm-svn: 312746
* [ORC] Convert null remote symbols to null JITSymbols.Lang Hames2017-09-051-10/+23
| | | | | | | | The existing code created a JITSymbol with an invalid materializer instead, guaranteeing a 'missing symbol' error when someone tried to materialize the symbol. llvm-svn: 312584
* [ORC] Add a pair of ORC layers that forward object-layer operations via RPC.Lang Hames2017-09-052-0/+577
| | | | | | | | | | | | | | | | | This patch introduces RemoteObjectClientLayer and RemoteObjectServerLayer, which can be used to forward ORC object-layer operations from a JIT stack in the client to a JIT stack (consisting only of object-layers) in the server. This is a new way to support remote-JITing in LLVM. The previous approach (supported by OrcRemoteTargetClient and OrcRemoteTargetServer) used a remote-mapping memory manager that sat "beneath" the JIT stack and sent fully-relocated binary blobs to the server. The main advantage of the new approach is that relocatable objects can be cached on the server and re-used (if the code that they represent hasn't changed), whereas fully-relocated blobs can not (since the addresses they have been permanently bound to will change from run to run). llvm-svn: 312511
* [ORC] Add an Error return to the JITCompileCallbackManager::grow method.Lang Hames2017-09-031-1/+1
| | | | | | | | Calling grow may result in an error if, for example, this is a callback manager for a remote target. We need to be able to return this error to the callee. llvm-svn: 312429
* Untabify.NAKAMURA Takumi2017-08-281-2/+3
| | | | llvm-svn: 311875
* Delete Default and JITDefault code modelsRafael Espindola2017-08-031-8/+2
| | | | | | | | | | | | | | | IMHO it is an antipattern to have a enum value that is Default. At any given piece of code it is not clear if we have to handle Default or if has already been mapped to a concrete value. In this case in particular, only the target can do the mapping and it is nice to make sure it is always done. This deletes the two default enum values of CodeModel and uses an explicit Optional<CodeModel> when it is possible that it is unspecified. llvm-svn: 309911
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-077-62/+90
| | | | | | | | This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. llvm-svn: 307350
* [ORC] Update GlobalMappingLayer::addModuleSet to addModule.Lang Hames2017-07-061-1/+1
| | | | | | This layer was accidentally left out of r306166. llvm-svn: 307319
* [Orc] Remove the memory manager argument to addModule, and de-templatize theLang Hames2017-07-043-54/+47
| | | | | | | | | | | | | | | | symbol resolver argument. De-templatizing the symbol resolver is part of the ongoing simplification of ORC layer API. Removing the memory management argument (and delegating construction of memory managers for RTDyldObjectLinkingLayer to a functor passed in to the constructor) allows us to build JITs whose base object layers need not be compatible with RTDyldObjectLinkingLayer's memory mangement scheme. For example, a 'remote object layer' that sends fully relocatable objects directly to the remote does not need a memory management scheme at all (that will be handled by the remote). llvm-svn: 307058
* [ORC] Re-apply r306166 and r306168 with fix for regression test.Lang Hames2017-06-234-33/+38
| | | | llvm-svn: 306182
* This reverts commit r306166 and r306168.Rafael Espindola2017-06-234-38/+33
| | | | | | | | | Revert "[ORC] Remove redundant semicolons from DEFINE_SIMPLE_CONVERSION_FUNCTIONS uses." Revert "[ORC] Move ORC IR layer interface from addModuleSet to addModule and fix the module type as std::shared_ptr<Module>." They broke ExecutionEngine/OrcMCJIT/test-global-ctors.ll on linux. llvm-svn: 306176
* [ORC] Move ORC IR layer interface from addModuleSet to addModule and fix theLang Hames2017-06-234-33/+38
| | | | | | module type as std::shared_ptr<Module>. llvm-svn: 306166
* [ORC] Switch the object layer API from addObjectSet to addObject (singular), andLang Hames2017-06-222-121/+110
| | | | | | | | | move the ObjectCache from the IRCompileLayer to SimpleCompiler. This is the first in a series of patches aimed at cleaning up and improving the robustness and performance of the ORC APIs. llvm-svn: 306058
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-0612-14/+14
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-092-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-1/+1
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* [IR] Abstract away ArgNo+1 attribute indexing as much as possibleReid Kleckner2017-05-031-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Do three things to help with that: - Add AttributeList::FirstArgIndex, which is an enumerator currently set to 1. It allows us to change the indexing scheme with fewer changes. - Add addParamAttr/removeParamAttr. This just shortens addAttribute call sites that would otherwise need to spell out FirstArgIndex. - Remove some attribute-specific getters and setters from Function that take attribute list indices. Most of these were only used from BuildLibCalls, and doesNotAlias was only used to test or set if the return value is malloc-like. I'm happy to split the patch, but I think they are probably easier to review when taken together. This patch should be NFC, but it sets the stage to change the indexing scheme to this, which is more convenient when indexing into an array: 0: func attrs 1: retattrs 2...: arg attrs Reviewers: chandlerc, pete, javed.absar Subscribers: david2050, llvm-commits Differential Revision: https://reviews.llvm.org/D32811 llvm-svn: 302060
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-141-1/+1
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* [ORC] Re-enable the Error/Expected unit tests that were disabled in r300177.Lang Hames2017-04-141-135/+133
| | | | | | | | | | | | | The tests were failing due to an occasional deadlock in SerializationTraits for Error: Both serializers and deserializers were protected by a single mutex and in the unit test (where both ends of the RPC are in the same process) one side might obtain the mutex, then block waiting for input, leaving the other side of the connection unable to obtain the mutex to write the data the first side was waiting for. Splitting the mutex into two (one for serialization, one for deserialization) appears to have fixed the issue. llvm-svn: 300286
* [ORC] Temporarily disable the RPC Error/Expected unit tests while I investigateLang Hames2017-04-131-133/+135
| | | | | | bot failures. llvm-svn: 300177
* [ORC] Remove more extraneous semicolons from r300167, rename the RPC ExpectedLang Hames2017-04-131-4/+4
| | | | | | tests to be consistent with the Error tests. llvm-svn: 300173
* [ORC] Add RPC and serialization support for Errors and Expecteds.Lang Hames2017-04-131-0/+192
| | | | | | | | | | | | | | This patch allows Error and Expected types to be passed to and returned from RPC functions. Serializers and deserializers for custom error types (types deriving from the ErrorInfo class template) can be registered with the SerializationTraits for a given channel type (see registerStringError in RPCSerialization.h for an example), allowing a given custom type to be sent/received. Unregistered types will be serialized/deserialized as StringErrors using the custom type's log message as the error string. llvm-svn: 300167
OpenPOWER on IntegriCloud