[ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.

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

3 files changed, 32 insertions, 32 deletions

diff --git a/docs/tutorial/BuildingAJIT1.rst b/docs/tutorial/BuildingAJIT1.rst
index f30b979579d..80957ee620f 100644
--- a/docs/tutorial/BuildingAJIT1.rst
+++ b/docs/tutorial/BuildingAJIT1.rst
@@ -190,14 +190,14 @@ available for execution.
     auto Resolver = createLambdaResolver(
         [&](const std::string &Name) {
           if (auto Sym = CompileLayer.findSymbol(Name, false))
-            return Sym.toRuntimeDyldSymbol();
-          return RuntimeDyld::SymbolInfo(nullptr);
+            return Sym;
+          return JITSymbol(nullptr);
         },
         [](const std::string &S) {
           if (auto SymAddr =
                 RTDyldMemoryManager::getSymbolAddressInProcess(Name))
-            return RuntimeDyld::SymbolInfo(SymAddr, JITSymbolFlags::Exported);
-          return RuntimeDyld::SymbolInfo(nullptr);
+            return JITSymbol(SymAddr, JITSymbolFlags::Exported);
+          return JITSymbol(nullptr);
         });
 
     // Build a singlton module set to hold our module.
@@ -242,28 +242,27 @@ implementation? By using a single symbol resolution scheme we are free to choose
 whatever makes the most sense for any given use case.
 
 Building a symbol resolver is made especially easy by the *createLambdaResolver*
-function. This function takes two lambdas [3]_ and returns a
-RuntimeDyld::SymbolResolver instance. The first lambda is used as the
-implementation of the resolver's findSymbolInLogicalDylib method, which searches
-for symbol definitions that should be thought of as being part of the same
-"logical" dynamic library as this Module. If you are familiar with static
-linking: this means that findSymbolInLogicalDylib should expose symbols with
-common linkage and hidden visibility. If all this sounds foreign you can ignore
-the details and just remember that this is the first method that the linker will
-use to try to find a symbol definition. If the findSymbolInLogicalDylib method
-returns a null result then the linker will call the second symbol resolver
-method, called findSymbol, which searches for symbols that should be thought of
-as external to (but visibile from) the module and its logical dylib. In this
-tutorial we will adopt the following simple scheme: All modules added to the JIT
-will behave as if they were linked into a single, ever-growing logical dylib. To
-implement this our first lambda (the one defining findSymbolInLogicalDylib) will
-just search for JIT'd code by calling the CompileLayer's findSymbol method. If
-we don't find a symbol in the JIT itself we'll fall back to our second lambda,
-which implements findSymbol. This will use the
-RTDyldMemoyrManager::getSymbolAddressInProcess method to search for the symbol
-within the program itself. If we can't find a symbol definition via either of
-these paths the JIT will refuse to accept our module, returning a "symbol not
-found" error.
+function. This function takes two lambdas [3]_ and returns a JITSymbolResolver
+instance. The first lambda is used as the implementation of the resolver's
+findSymbolInLogicalDylib method, which searches for symbol definitions that
+should be thought of as being part of the same "logical" dynamic library as this
+Module. If you are familiar with static linking: this means that
+findSymbolInLogicalDylib should expose symbols with common linkage and hidden
+visibility. If all this sounds foreign you can ignore the details and just
+remember that this is the first method that the linker will use to try to find a
+symbol definition. If the findSymbolInLogicalDylib method returns a null result
+then the linker will call the second symbol resolver method, called findSymbol,
+which searches for symbols that should be thought of as external to (but
+visibile from) the module and its logical dylib. In this tutorial we will adopt
+the following simple scheme: All modules added to the JIT will behave as if they
+were linked into a single, ever-growing logical dylib. To implement this our
+first lambda (the one defining findSymbolInLogicalDylib) will just search for
+JIT'd code by calling the CompileLayer's findSymbol method. If we don't find a
+symbol in the JIT itself we'll fall back to our second lambda, which implements
+findSymbol. This will use the RTDyldMemoyrManager::getSymbolAddressInProcess
+method to search for the symbol within the program itself. If we can't find a
+symbol definition via either of these paths the JIT will refuse to accept our
+module, returning a "symbol not found" error.
 
 Now that we've built our symbol resolver we're ready to add our module to the
 JIT. We do this by calling the CompileLayer's addModuleSet method [4]_. Since
diff --git a/docs/tutorial/BuildingAJIT2.rst b/docs/tutorial/BuildingAJIT2.rst
index 8fa92317f54..839875266a2 100644
--- a/docs/tutorial/BuildingAJIT2.rst
+++ b/docs/tutorial/BuildingAJIT2.rst
@@ -93,8 +93,8 @@ define below.
   auto Resolver = createLambdaResolver(
       [&](const std::string &Name) {
         if (auto Sym = OptimizeLayer.findSymbol(Name, false))
-          return Sym.toRuntimeDyldSymbol();
-        return RuntimeDyld::SymbolInfo(nullptr);
+          return Sym;
+        return JITSymbol(nullptr);
       },
   // ...
 
diff --git a/docs/tutorial/BuildingAJIT3.rst b/docs/tutorial/BuildingAJIT3.rst
index 216e65c6fa1..fa197c59a6b 100644
--- a/docs/tutorial/BuildingAJIT3.rst
+++ b/docs/tutorial/BuildingAJIT3.rst
@@ -113,10 +113,11 @@ to create the compile callback needed for each function.
 Next we have to update our constructor to initialize the new members. To create
 an appropriate compile callback manager we use the
 createLocalCompileCallbackManager function, which takes a TargetMachine and a
-TargetAddress to call if it receives a request to compile an unknown function.
-In our simple JIT this situation is unlikely to come up, so we'll cheat and
-just pass '0' here. In a production quality JIT you could give the address of a
-function that throws an exception in order to unwind the JIT'd code's stack.
+JITTargetAddress to call if it receives a request to compile an unknown
+function.  In our simple JIT this situation is unlikely to come up, so we'll
+cheat and just pass '0' here. In a production quality JIT you could give the
+address of a function that throws an exception in order to unwind the JIT'd
+code's stack.
 
 Now we can construct our CompileOnDemandLayer. Following the pattern from
 previous layers we start by passing a reference to the next layer down in our