From 1972fa3616af55c223096e9b11465f580530d88f Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Fri, 22 Sep 2017 08:24:14 -0700 Subject: 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. --- source/slang/core.meta.slang.cpp | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'source/slang/core.meta.slang.cpp') 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"; } -- cgit v1.2.3