All of these existed because MSVC 2013 was unable to synthesize default
move ctors. We recently dropped support for it so all that error-prone
boilerplate can go.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284721 91177308-0d34-0410-b5e6-96231b3b80d8
It should forward to deregisterEHFramesInProcess by default, not
registerEHFramesInProcess.
No test case: I haven't come up with a good way to unit test EH frame
registration yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283123 91177308-0d34-0410-b5e6-96231b3b80d8
class.
SerializationTraits provides serialize and deserialize methods corresponding to
the earlier functions, but also provides a name for the type. In future, this
name will be used to render function signatures as strings, which will in turn
be used to negotiate and verify API support between RPC clients and servers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281254 91177308-0d34-0410-b5e6-96231b3b80d8
Still no unit test due to synchronization bugs on s390. These issues were
discovered in an out-of-tree utility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280163 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280100 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280051 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280016 91177308-0d34-0410-b5e6-96231b3b80d8
switch to using one indirect stub manager per logical dylib rather than one per
input module.
LogicalDylib is a helper class used by the CompileOnDemandLayer to manage
symbol resolution between modules during lazy compilation. In particular, it
ensures that internal symbols resolve correctly even in the case where multiple
input modules contain the same internal symbol name (which must to be promoted
to external hidden linkage so that functions in any given module can be split
out by lazy compilation). LogicalDylib's resolution scheme (before this commit)
required one stub-manager per input module. This made recompilation of functions
(by adding a module containing a new definition) difficult, as the stub manager
for any given symbol was bound to the module that supplied the original
definition. By using one stubs manager for the whole logical dylib symbols can
be more easily replaced, although support for doing this is not included in this
patch (it will be implemented in a follow up).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279952 91177308-0d34-0410-b5e6-96231b3b80d8
ExecutionEngine::runFunction is supposed to allow execution of arbitrary
function types, but MCJIT can only reasonably support a limited subset of
main-linke function types. This patch documents this limitation, and fixes
MCJIT::runFunction to abort with a meaningful error at runtime if called with
an unsupported function type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278348 91177308-0d34-0410-b5e6-96231b3b80d8
It breaks ExecutionEngine/OrcLazy/weak-function.ll on most bots.
Script:
--
...
--
Exit Code: 1
Command Output (stderr):
--
Could not find main function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277907 91177308-0d34-0410-b5e6-96231b3b80d8
This adds partial support for weak functions to the CompileOnDemandLayer by
modifying the addLogicalModule method to check for existing stub definitions
before building a new stub for a weak function. This scheme is sufficient to
support ODR definitions, but fails for general weak definitions if strong
definition is encountered after the first weak definition. (A more extensive
refactor will be required to fully support weak symbols).
This patch does *not* add weak symbol support to RuntimeDyld: I hope to add
that in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277896 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents handles from being invalidated (through iterator invalidation)
when new modules are added.
No test-case yet: This bug was uncovered during work on an upcoming patch for
weak symbol support and the testcase for that feature will implicitly test for
correct behavior here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277847 91177308-0d34-0410-b5e6-96231b3b80d8
Common symbol support in ORC was broken in r270716 when the symbol resolution
rules in RuntimeDyld were changed. With the switch to lazily materialized
symbols in r277386, common symbols can be supported by having
RuntimeDyld::emitCommonSymbols search for (but not materialize!) definitions
elsewhere in the logical dylib.
This patch adds the 'Common' flag to JITSymbolFlags, and the necessary check
to RuntimeDyld::emitCommonSymbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277397 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277386 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it possible to implement re-optimization on top of the
CompileOnDemandLayer.
Test case to come in a future patch: This will need an execution test, and
execution tests require a full working stack. The best option is to plumb this
API up to the C Bindings stack and add a C bindings test for this.
Patch by Sean Ogden. Thanks Sean!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277257 91177308-0d34-0410-b5e6-96231b3b80d8
This allows ErrorAsOutParameter to work better with "optional" errors. For
example, consider a function where for certain input values it is known that
the function can't fail. This can now be written as:
Result foo(Arg X, Error *Err) {
ErrorAsOutParameter EAO(Err);
if (<Error Condition>) {
if (Err)
*Err = <report error>;
else
llvm_unreachable("Unexpected failure!");
}
}
Rather than having to construct an ErrorAsOutParameter under every conditional
where Err is known to be non-null.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276430 91177308-0d34-0410-b5e6-96231b3b80d8
This is a convenience iterator that allows clients to enumerate the
GlobalObjects within a Module.
Also start using it in a few places where it is obviously the right thing
to use.
Differential Revision: http://reviews.llvm.org/D21580
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273470 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271350 91177308-0d34-0410-b5e6-96231b3b80d8
This function failed to type-check as it was. No test case yet (we only have
regression tests for the remote-JIT code, and LLI don't use this function), but
an upcoming chapter of the Kaleidoscope Building A JIT tutorials will use
this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271189 91177308-0d34-0410-b5e6-96231b3b80d8
Global variables and aliases are emitted eagerly, but there may not be any in
the incoming module. In that case, we can save some memory and compile time by
not building, emitting and tracking an empty globals module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270908 91177308-0d34-0410-b5e6-96231b3b80d8
searching for external symbols, and fall back to the SymbolResolver::findSymbol
method if the former returns null.
This makes RuntimeDyld behave more like a static linker: Symbol definitions
from within the current module's "logical dylib" will be preferred to
external definitions. We can build on this behavior in the future to properly
support weak symbol handling.
Custom symbol resolvers that override the findSymbolInLogicalDylib method may
notice changes due to this patch. Clients who have not overridden this method
should generally be unaffected, however users of the OrcMCJITReplacement class
may notice changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270716 91177308-0d34-0410-b5e6-96231b3b80d8
Having an enum member named Default is quite confusing: Is it distinct
from the others?
This patch removes that member and instead uses Optional<Reloc> in
places where we have a user input that still hasn't been maped to the
default value, which is now clear has no be one of the remaining 3
options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269988 91177308-0d34-0410-b5e6-96231b3b80d8
