Callable CPU code support (#1014)

* First pass support for compiling to a loaded shared library.

* Improve documentation for cpu target.

* Removed the SLANG_COMPILE_FLAG_LOAD_SHARED_LIBRARY flag.
Use the SLANG_HOST_CALLABLE code target
Document mechanism.

* Fix typo in cpp-resource.slang
In test code if the target is 'callable' we don't need to compile (indeed there is no source file).

* Small refactor using CommandLineCPPCompiler as base class to implement VisualStudioCPPCompiler and GCCCPPCompiler.

* Improvements around CPPCompiler.
Mechanism to know products produced.
Cleaning up products after execution.

* Fix multiple definition of 'SourceType'

1 files changed, 30 insertions, 12 deletions

diff --git a/docs/cpu-target.md b/docs/cpu-target.md
index dc2319b6f..f86b7d6c5 100644
--- a/docs/cpu-target.md
+++ b/docs/cpu-target.md
@@ -9,6 +9,7 @@ Slang has preliminary support for producing CPU source and binaries.
 * Can compile Slang source into C++ source code
 * Supports compute style shaders
 * C/C++ backend abstracts the command line options, and parses the compiler errors/out such that all supported compilers output available in same format 
+* Once compilation is complete can optionally access and run CPU code directly
 
 # Limitations
 
@@ -41,18 +42,19 @@ To make it possible for slang to produce CPU code, we now need a mechanism to co
 In the API the `SlangCompileTarget`s are 
 
 ```
-SLANG_C_SOURCE,             ///< The C language
-SLANG_CPP_SOURCE,           ///< The C++ language
+SLANG_C_SOURCE             ///< The C language
+SLANG_CPP_SOURCE           ///< The C++ language
 ```        
    
 If a CPU binary is required this can be specified as a `SlangCompileTarget` of 
    
 ```   
-SLANG_EXECUTABLE,           ///< Executable (for hosting CPU/OS)
-SLANG_SHARED_LIBRARY,       ///< A shared library/Dll (for hosting CPU/OS)
+SLANG_EXECUTABLE           ///< Executable (for hosting CPU/OS)
+SLANG_SHARED_LIBRARY       ///< A shared library/Dll (for hosting CPU/OS)
+SLANG_HOST_CALLABLE        ///< A CPU target that makes the compiled code available to be run immediately
 ```
 
-These can also be specified on the slang command line as `-target exe` and `-target dll` or `-target sharedlib`.
+These can also be specified on the slang command line as `-target exe` and `-target dll` or `-target sharedlib`. `-target callable` or `-target host-callable` is also possible, but is typically not very useful from the command line, other than to test such code is avaiable for host execution.
 
 In order to be able to use the slang code on CPU, there needs to be binding via values passed to a function that the C/C++ code will produce and export. How this works is described in the ABI section. 
 
@@ -60,6 +62,27 @@ If a binary target is requested, the binary contents will be returned in a ISlan
 
 Under the covers when slang is used to generate a binary via a C/C++ compiler, it must do so through the file system. Currently this means that the source (say generated by slang) and the binary (produced by the C/C++ compiler) must all be files. To make this work slang uses temporary files. That the reasoning for hiding this mechanism - and not return say filenames, is so that in the future when binaries are produced directly (for example with LLVM), nothing will need to change.  
 
+Executing CPU Code
+==================
+
+In typically slang operation when code is compiled it produces either source or a binary that can then be loaded by another API such as a rendering API. With CPU code the binary produced could be saved to a file and then executed as an exe or a shared library/dll. In practice though it is not uncommon to want to be able to execute compiled code immediately. Having to save off to a file and then load again can be awkward. It is also not necessarily the case that code needs to be saved to a file to be executed. 
+
+To handle being able call code directly, code can be compiled using the SLANG_HOST_CALLABLE code target type. To access the code that has been produced use the function
+
+```
+    SLANG_API SlangResult spGetEntryPointHostCallable(
+        SlangCompileRequest*    request,
+        int                     entryPointIndex,
+        int                     targetIndex,
+        ISlangSharedLibrary**   outSharedLibrary);
+```        
+
+This outputs a `ISlangSharedLibrary` which whilst in scope, any contained functions remain available (even if the request or session go out of scope). The contained functions can then be accessed via the `findFuncByName` method on the `ISlangSharedLibrary` interface.
+
+The returned function pointer should be cast to the appropriate function signature before calling. For entry points - the function will appear under the same name as the entry point name. See the ABI section for what is the appropriate signature for entry points. 
+
+For pass through compilation of C/C++ this mechanism allows any functions marked for export to be directly queried. 
+
 ABI
 ===
 
@@ -188,24 +211,19 @@ TODO
 # Main
 
 * Complete support (in terms of interfaces) for 'complex' resource types - such as Texture
-* Interface implementation for complex resource types
 * Parameter block support (the difficulty is around layout)
 * Split out entry point uniforms into a separate pointer passed to the entry point
-* Test system executes and tests for CPU targets 
-* Slang API allows for compilation into loaded binary such that functions can be directly executed
-* Output C/C++ compiler errors as 'externalCompiler' errors through diagnostic system
+* Test system executes and tests for CPU targets - for example compute tests run on CPU 
 * Improve documentation
 * Output of header files 
-* Mechanism to specify where C/C++ binaries are located
 
 # Internal Slang compiler features
 
 These issues are more internal Slang features/improvements 
 
-* Currently we only support 64 bit targets (it is assumed in layout that pointers are 64 bit)
 * Slang compute tests work (where appropriate)
 * Currently only generates C++ code, it would be fairly straight forward to support C (especially if we have 'intrinsic definitions')
 * Have 'intrinsic definitions' in standard library - such that they can be generated where appropriate 
   + This will simplify the C/C++ code generation as means slang language will generate must of the appropriate code
 * Currently 'construct' IR inst is supported as is, we may want to split out to separate instructions for specific scenarios
-
+* Refactoring around swizzle. Currently in emit it has to check for a variety of scenarios - could be simplified with an IR pass and perhaps more specific instructions.