summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine/Orc/RPCUtilsTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Break out OrcError and RPCChris Bieneman2019-10-291-1/+1
| | | | | | | | | | | | | | | | | | | Summary: When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more. This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory. With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport. Reviewers: lhames Reviewed By: lhames Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68732
* [ORC][RPC] Join server thread before checking condition in unit test.Lang Hames2019-09-061-2/+2
| | | | | | Otherwise we have a race on the sent-messages count. llvm-svn: 371263
* [ORC] Make sure RPC channel-send is called in blocking calls and responses.Lang Hames2019-09-061-0/+11
| | | | | | | | | ORC-RPC batches calls by default, and the channel's send method must be called to transfer any buffered calls to the remote. The call to send was missing on responses and blocking calls in the SingleThreadedRPCEndpoint. This patch adds the necessary calls and modifies the RPC unit test to check for them. llvm-svn: 371245
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [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] 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] 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
* [ORC] Use native Errors rather than converted std::error_codes for ORC RPC.Lang Hames2017-04-131-3/+3
| | | | llvm-svn: 300155
* [Orc] Break QueueChannel out into its own header and add a utility,Lang Hames2017-04-061-82/+39
| | | | | | createPairedQueueChannels, to simplify channel creation in the RPC unit tests. llvm-svn: 299611
* [Orc][RPC] Accept both const char* and char* arguments for string serialization.Lang Hames2017-02-241-0/+45
| | | | llvm-svn: 296168
* [Orc][RPC] Add a AsyncHandlerTraits specialization for non-value-type responseLang Hames2017-02-151-0/+51
| | | | | | | | | | handler args. The specialization just inherits from the std::decay'd response handler type. This allows member functions (via MemberFunctionWrapper) to be used as async handlers. llvm-svn: 295151
* [Orc][RPC] Remove lanch policies in favor of async handlers.Lang Hames2017-02-141-2/+48
| | | | | | | | | | | | | | | Launch policies provided a mechanism for running RPC handlers on a background thread (unblocking the main RPC receiver thread). Async handlers generalize this by passing the responder function (the function that sends the RPC return value) as an argument to the handler. The handler can optionally do its work on a background thread (the same way launch policies do), but can also (a) can inspect the call arguments before deciding to run the work on a different thread, or (b) can use the responder in a subsequent RPC call (e.g. in the handler of a callAsync), allowing the handler to call back to the originator (or to a 3rd party) without blocking the listener thread, and without launching a new thread. llvm-svn: 295030
* Silence redundant semicolon warnings. NFC.Michael Kuperstein2017-02-131-2/+2
| | | | llvm-svn: 295005
* [Orc][RPC] Add a HandlerTratis specialization for free functions.Lang Hames2017-02-081-0/+9
| | | | llvm-svn: 294392
* [Orc][RPC] Refactor ParallelCallGroup to decouple it from RPCEndpoint.Lang Hames2017-01-241-8/+8
| | | | | | | | This refactor allows parallel calls to be made via an arbitrary async call dispatcher. In particular, this allows ParallelCallGroup to be used with derived RPC classes that expose custom async RPC call operations. llvm-svn: 292891
* [Orc][RPC] Add 'removeHandler' and 'clearHandlers' methods to RPC endpoints.Lang Hames2017-01-211-0/+26
| | | | | | | This can be used to free handler resources for handlers that won't be called again. llvm-svn: 292714
* unittest: remove extraneous ';'Saleem Abdulrasool2017-01-081-1/+1
| | | | | | Silences a warning from gcc:6. NFC llvm-svn: 291394
* [Orc][RPC] Fix typo.Lang Hames2017-01-081-1/+1
| | | | llvm-svn: 291381
* [Orc][RPC] Add an APICalls utility for grouping RPC funtions for registration.Lang Hames2017-01-081-2/+50
| | | | | | | | | | | | | APICalls allows groups of functions to be composed into an API that can be registered as a unit with an RPC endpoint. Doing registration on a-whole API basis (rather than per-function) allows missing API functions to be detected early. APICalls also allows Function membership to be tested at compile-time. This allows clients to write static assertions that functions to be called are members of registered APIs. llvm-svn: 291380
* [Orc][RPC] Rename Single/MultiThreadedRPC to Single/MultithreadedRPCEndpoint.Lang Hames2017-01-071-3/+2
| | | | llvm-svn: 291374
* [Orc][RPC] Add a ParallelCallGroup utility for dispatching and waiting onLang Hames2016-12-251-0/+71
| | | | | | | | | | | | | | | | multiple asynchronous RPC calls. ParallelCallGroup allows multiple asynchronous calls to be dispatched, and provides a wait method that blocks until all asynchronous calls have been executed on the remote and all return value handlers run on the local machine. This will allow, for example, the JIT client to issue memory allocation calls for all sections in parallel, then block until all memory has been allocated on the remote and the allocated addresses registered with the client, at which point the JIT client can proceed to applying relocations. llvm-svn: 290523
* [Orc][RPC] Actually specialize SerializationTraits and RPCTypeName in the rightLang Hames2016-12-211-24/+40
| | | | | | | | namespace. r290226 was a think-o - just qualifying the name doesn't count. llvm-svn: 290230
* [Orc][RPC] Specialize RPCTypeName and SerializationTraits in the right ↵Lang Hames2016-12-211-3/+3
| | | | | | namespace. llvm-svn: 290226
* [Orc] Add some static-assert checks to improve the error messages for RPC callsLang Hames2016-12-211-0/+126
| | | | | | | | and handler registrations. Also add a unit test for alternate-type serialization/deserialization. llvm-svn: 290223
* Remove a stale test case.Lang Hames2016-11-171-22/+0
| | | | llvm-svn: 287183
* [Orc] Re-enable the RPC unit test disabled in r286917.Lang Hames2016-11-161-168/+163
| | | | | | | | | This unit test infinite-looped on s390x due to a thread_yield being optimized out. I've updated the QueueChannel class (where thread_yield was called) to use a condition variable instead. This should cause the unit test to behave correctly. llvm-svn: 287121
* [ORC] Temporarily disable RPCUtils unit test.Lang Hames2016-11-151-152/+153
| | | | | | | This broke s390x due to a bug in the QueueChannel implementation that led to it infinite-looping. Disabling it while I look into a fix. llvm-svn: 286917
* [ORC] Add a WrappedHandlerReturn type to map handler return types onto errorLang Hames2016-11-121-1/+1
| | | | | | | | | | | | | return types. This class allows user provided handlers to return either error-wrapped types or plain types. In the latter case, the plain type is wrapped with a success value of Error or Expected<T> type to fit it into the rest of the serialization machinery. This patch allows us to remove the RPC unit-test workaround added in r286646. llvm-svn: 286701
* [ORC] Temporarily fix the RPCUtils unit test by explicitly specifying a handlerLang Hames2016-11-111-1/+1
| | | | | | | | | return type. This should be fixed permanently by having the RPCUtils header recognize the ErrorSuccess type. I'll commit that in a follow up patch. llvm-svn: 286646
* [ORC] Re-apply 286620 with fixes for the ErrorSuccess class.Lang Hames2016-11-111-86/+150
| | | | llvm-svn: 286639
* [ORC] Revert r286620 while I investigate a bot failure.Lang Hames2016-11-111-150/+86
| | | | llvm-svn: 286621
* [ORC] Refactor the ORC RPC utilities to add some new features.Lang Hames2016-11-111-86/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Add support for function key negotiation. The previous version of the RPC required both sides to maintain the same enumeration for functions in the API. This means that any version skew between the client and server would result in communication failure. With this version of the patch functions (and serializable types) are defined with string names, and the derived function signature strings are used to negotiate the actual function keys (which are used for efficient call serialization). This allows clients to connect to any server that supports a superset of the API (based on the function signatures it supports). (2) Add a callAsync primitive. The callAsync primitive can be used to install a return value handler that will run as soon as the RPC function's return value is sent back from the remote. (3) Launch policies for RPC function handlers. The new addHandler method, which installs handlers for RPC functions, takes two arguments: (1) the handler itself, and (2) an optional "launch policy". When the RPC function is called, the launch policy (if present) is invoked to actually launch the handler. This allows the handler to be spawned on a background thread, or added to a work list. If no launch policy is used, the handler is run on the server thread itself. This should only be used for short-running handlers, or entirely synchronous RPC APIs. (4) Zero cost cross type serialization. You can now define serialization from any type to a different "wire" type. For example, this allows you to call an RPC function that's defined to take a std::string while passing a StringRef argument. If a serializer from StringRef to std::string has been defined for the channel type this will be used to serialize the argument without having to construct a std::string instance. This allows buffer reference types to be used as arguments to RPC calls without requiring a copy of the buffer to be made. llvm-svn: 286620
* [ORC] Fix the RPC unit test for header changes in r281171.Lang Hames2016-09-111-2/+2
| | | | llvm-svn: 281173
* Re-instate recent RPC updates (r280016, r280017, r280027, r280051) with aLang Hames2016-08-301-7/+7
| | | | | | workaround for the limitations of MSVC 2013's std::future class. llvm-svn: 280141
* Revert "[ORC][RPC] Make the future type of an Orc RPC call Error/Expected ↵Reid Kleckner2016-08-301-7/+7
| | | | | | | | | | | | | rather than" This reverts commit r280016, and the followups of r280017, r280027, r280051, r280058, and r280059. MSVC's implementation of std::promise does not get along with llvm::Error. It uses its promised value too much like a normal value type. llvm-svn: 280100
* [ORC][RPC] Reword 'async' to 'non-blocking' to better reflect call primitiveLang Hames2016-08-301-3/+3
| | | | | | | | | | | | | | behaviors, and add a callB (blacking call) primitive. callB is a blocking call primitive for threaded code where the RPC responses are being processed on a separate thread. (For single threaded code callST should continue to be used instead). No unit test yet: Last time I commited a threaded unit test it deadlocked on one of the s390x builders. I'll try to re-enable that test first, and add a new test if I can sort out the deadlock issue. llvm-svn: 280051
* [ORC] Fix unit-test breakage from r280016.Lang Hames2016-08-291-2/+2
| | | | | | | Void functions returning error now boolean convert to 'false' if they succeed. Unit tests updated to reflect this. llvm-svn: 280027
* [ORC][RPC] Make the future type of an Orc RPC call Error/Expected rather thanLang Hames2016-08-291-4/+4
| | | | | | | | | | | | | | | | Optional. For void functions the return type of a nonblocking call changes from Expected<future<Optional<bool>>> to Expected<future<Error>>, and for functions returning T the return type changes from Expected<future<Optional<T>>> to Expected<future<Expected<T>>>. Inner results need to be checked (since the RPC connection may have dropped out before a result came back) and Error/Expected provide stronger checking requirements. It also allows us drop the crufty 'optionalToError' function and just collapse Errors in the single-threaded call primitives. llvm-svn: 280016
* [ORC] clang-format code that was touched in r267457. NFC.Lang Hames2016-04-251-74/+39
| | | | | | | Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
* [ORC] Thread Error/Expected through the RPC library.Lang Hames2016-04-251-8/+8
| | | | | | | | | | This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
* [Orc] Disable RPC callST unit test until the S390 failures encountered duringLang Hames2016-04-191-20/+22
| | | | | | | http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/3459 can be debugged/fixed. llvm-svn: 266717
* [Orc] Tidy up some of the RPC primitives, add a unit-test for the callSTLang Hames2016-04-191-42/+95
| | | | | | (synchronous call) primitive. llvm-svn: 266711
* [Orc] Re-commit r266581 with fixes for MSVC, and format cleanups.Lang Hames2016-04-181-27/+76
| | | | | | | | | | Fixes: (1) Removes constexpr (unsupported in MSVC) (2) Move constructors (remove explicitly defaulted ones) (3) <future> - Add warning suppression for MSVC. llvm-svn: 266663
* Revert 266581 (and follow-up 266588), it doesn't build on Windows.Nico Weber2016-04-181-76/+27
| | | | | | | | | | Three problems: 1. <future> can't be easily used. If you must use it, see include/Support/ThreadPool.h for how. 2. constexpr problems, even after 266588. 3. Move assignment operators can't be defaulted in MSVC2013. llvm-svn: 266615
* [ORC] Generalize the ORC RPC utils to support RPC function return values andLang Hames2016-04-181-27/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | asynchronous call/handle. Also updates the ORC remote JIT API to use the new scheme. The previous version of the RPC tools only supported void functions, and required the user to manually call a paired function to return results. This patch replaces the Procedure typedef (which only supported void functions) with the Function typedef which supports return values, e.g.: Function<FooId, int32_t(std::string)> Foo; The RPC primitives and channel operations are also expanded. RPC channels must support four new operations: startSendMessage, endSendMessage, startRecieveMessage and endRecieveMessage, to handle channel locking. In addition, serialization support for tuples to RPCChannels is added to enable multiple return values. The RPC primitives are expanded from callAppend, call, expect and handle, to: appendCallAsync - Make an asynchronous call to the given function. callAsync - The same as appendCallAsync, but calls send on the channel when done. callSTHandling - Blocking call for single-threaded code. Wraps a call to callAsync then waits on the result, using a user-supplied handler to handle any callbacks from the remote. callST - The same as callSTHandling, except that it doesn't handle callbacks - it expects the result to be the first return. expect and handle - as before. handleResponse - Handle a response from the remote. waitForResult - Wait for the response with the given sequence number to arrive. llvm-svn: 266581
* [Orc] Switch RPC Procedure to take a function type, rather than an arg list.Lang Hames2016-03-211-12/+4
| | | | | | No functional change, just a little more readable. llvm-svn: 263951
* [Orc] Add support for remote JITing to the ORC API.Lang Hames2016-01-111-0/+147
This patch adds utilities to ORC for managing a remote JIT target. It consists of: 1. A very primitive RPC system for making calls over a byte-stream. See RPCChannel.h, RPCUtils.h. 2. An RPC API defined in the above system for managing memory, looking up symbols, creating stubs, etc. on a remote target. See OrcRemoteTargetRPCAPI.h. 3. An interface for creating high-level JIT components (memory managers, callback managers, stub managers, etc.) that operate over the RPC API. See OrcRemoteTargetClient.h. 4. A helper class for building servers that can handle the RPC calls. See OrcRemoteTargetServer.h. The system is designed to work neatly with the existing ORC components and functionality. In particular, the ORC callback API (and consequently the CompileOnDemandLayer) is supported, enabling lazy compilation of remote code. Assuming this doesn't trigger any builder failures, a follow-up patch will be committed which tests these utilities by using them to replace LLI's existing remote-JITing demo code. llvm-svn: 257305
OpenPOWER on IntegriCloud