summaryrefslogtreecommitdiffstats
path: root/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/toy.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-19/+19
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-301-3/+6
| | | | | | | | | 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] Refactor OrcRemoteTarget code to expose its RPC API, reduceLang Hames2017-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | code duplication in the client, and improve error propagation. This patch moves the OrcRemoteTarget rpc::Function declarations from OrcRemoteTargetRPCAPI into their own namespaces under llvm::orc::remote so that they can be used in new contexts (in particular, a remote-object-file adapter layer that I will commit shortly). Code duplication in OrcRemoteTargetClient (especially in loops processing the code, rw-data and ro-data allocations) is removed by moving the loop bodies into their own functions. Error propagation is (slightly) improved by adding an ErrorReporter functor to the OrcRemoteTargetClient -- Errors that can't be returned (because they occur in destructors, or behind stable APIs that don't provide error returns) can be sent to the ErrorReporter instead. Some methods in the Client API are also changed to make better use of the Expected class: returning Expected<T>s rather than returning Errors and taking T&s to store the results. llvm-svn: 312500
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-071-1/+1
| | | | | | | | 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
* Use print() instead of dump() in codeMatthias Braun2017-01-281-1/+2
| | | | | | | The dump() functions are meant to be used in a debugger, code should typically use something like print(errs()); llvm-svn: 293365
* [Examples] Fix some Clang-tidy modernize-use-default and Include What You ↵Eugene Zelenko2016-11-181-9/+20
| | | | | | | | Use warnings; other minor fixes. Differential revision: https://reviews.llvm.org/D26433 llvm-svn: 287384
* [ORC] Re-apply 286620 with fixes for the ErrorSuccess class.Lang Hames2016-11-111-3/+3
| | | | llvm-svn: 286639
* [ORC] Revert r286620 while I investigate a bot failure.Lang Hames2016-11-111-3/+3
| | | | llvm-svn: 286621
* [ORC] Refactor the ORC RPC utilities to add some new features.Lang Hames2016-11-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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
* [Kaleidoscope][BuildingAJIT] Add code for Chapter 5 - remote JITing.Lang Hames2016-05-301-0/+1294
This chapter demonstrates lazily JITing from ASTs with the expressions being executed on a remote machine via a TCP connection. It needs some polish, but is substantially complete. Currently x86-64 SysV ABI (Darwin and Linux) only, but other architectures can be supported by changing the server code to use alternative ABI support classes from llvm/include/llvm/ExecutionEngine/Orc/OrcABISupport.h. llvm-svn: 271193
OpenPOWER on IntegriCloud