(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
Chapter 5.
Chapter 5 demonstrates remote JITing: code is executed on the remote, not the
machine running the REPL, so it's the remote's triple (and TargetMachine) that
we need.
llvm-svn: 284657
This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class
that is capable of lazy materialization (i.e. the symbol definition needn't be
emitted until the address is requested). This can be used to support common
and weak symbols in the JIT (though this is not implemented in this patch).
For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver.
For space efficiency a new class, JITEvaluatedSymbol, is introduced that
behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an
address and symbol flags. Instances of JITEvaluatedSymbol can be used in
symbol-tables to avoid paying the space cost of the materializer.
llvm-svn: 277386
This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo
instances from JITSymbols. It will save more mess in the future when
JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather
than just a TargetAddress, since we'll be able to embed the error checking in
the conversion.
llvm-svn: 271350
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
Symbol resolution should be done on the top layer of the stack unless there's a
good reason to do otherwise. In this case it would have worked because
OptimizeLayer::addModuleSet eagerly passes all modules down to the
CompileLayer, meaning that searches in CompileLayer will find the definitions.
In later chapters where the top layer's addModuleSet isn't a pass-through, this
would break.
llvm-svn: 270899
This is a work in progress - the chapter text is incomplete, though
the example code compiles and runs.
Feedback and patches are, as usual, most welcome.
llvm-svn: 270487
NAKAMURA Takumi