More work on IR-based lowering and cross-compilation

None of these changes are made "live" at the moment. I'm just trying to get them checked in to avoid divering too far from `master` at any point during development.

- Add basic emit logic to produce GLSL from the IR in a few cases (the existing IR emit logic was ad hoc and HLSL-specific)

- When lowering a function declaration, walk up its chain of parent declarations to collect additional parameters as needed

- When lowering a call, make sure to add generic arguments that come from the declaration reference being called

- Attach a "mangled name" to symbols when lowering, so that we can eventually use that name to resolve things for linkage.

- After the above work, I had to apply some fixups to make sure that generic arguments *don't* get added when the user is calling an `__intrinsic_op` function, since those should map 1-to-1 down to instructions with just their ordinary parameter list.

A big open question right now is whether I should continue to represent the generic arguments as just part of the ordinary argument list for a function, or split them out into separate `applyGeneric` and `apply` steps.
A strongly related question is whether a declaration with generic parameters should lower into a single declaration, or one declaration nested inside an outer generic declaration.

A good future step at this point would be to eliminate a lot of the `__intrinsic_op` stuff in favor of having the builtin functions include their own definitions, which might be in terms of a new expression-level construct for writing inline IR operations. This can't be done until the existing AST-to-AST path is no longer needed for cross-compilation purposes.

More immediate next steps here:

- We need a way to round-trip calls to external declaration that get handled by this mangled-name logic. Basically, if we are asked to output HLSL and we see a call to `_S...GetDimensions...(float4, t, a, ...)` we need to be able to walk the mangled name and get back to `t.getDimensions(a, ...)` without a whole lot of manual definitions to make things round-trip.

- In the other case, where a declaration isn't built-in for the chosen target, we need to be able to load a module of target-specific definitions (which will somehow map back to symbols with certain mangled names) and then look these up (by mangled name) and then load/link/inline them into the user's IR to satisfy requirements in their code.

1 files changed, 7 insertions, 1 deletions

diff --git a/source/slang/core.meta.slang.cpp b/source/slang/core.meta.slang.cpp
index 8395f11f5..cf2052d3c 100644
--- a/source/slang/core.meta.slang.cpp
+++ b/source/slang/core.meta.slang.cpp
@@ -95,6 +95,7 @@ sb << "    typedef T Element;\n";
 
 // Declare initializer taking a single scalar of the elemnt type
 sb << "    __implicit_conversion(" << kConversionCost_ScalarToVector << ")\n";
+sb << "    __intrinsic_op(" << kIROp_constructVectorFromScalar << ")\n";
 sb << "    __init(T value);\n";
 
 sb << "};\n";
@@ -426,7 +427,12 @@ for (int tt = 0; tt < kBaseTextureTypeCount; ++tt)
 
 
                     sb << ")\")\n";
-                    sb << "__intrinsic_op\n";
+
+
+					// TIM: Making `GetDimensions` *not* be marked as
+					// an intrinsic, just so we can see how defining
+					// things as `extern` functions would work.
+//                    sb << "__intrinsic_op\n";
 
                 }