From f145e09a6dcbcf326f782b3e6a76dbf291c792cf Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Wed, 28 Jun 2017 13:34:38 -0700 Subject: Start to support cross-compilation via "lowering" pass - The big change here is the introduction of a "lowering" pass that takes an input AST from the semantic checker, and produces an output AST suitable for emitting. The intention is that he lowering pass is responsible for: - Stripping out unused code (when we have enough information to do so), by only outputting declarations that are transitively references from an entry point - When cross-compiling to GLSL, generating a suitable `void main()` entry point to wrap the user-written entry-point function - (Eventually) legalizing types in the program, by scalarizing aggregate types that mix uniform and resource types - (Eventually) instantiating generic declarations so that the resulting code only deals with fully specialized declarations - (Eventually) de-sugaring OOP constructs into basic "structs and functions" form - (Eventually) instantiating code that depends on interface types at the concrete types chosen - It is clear that there is still a lot of work to be done there, to this change is really about getting infrastructure in place without breaking the existing test cases. - One cleanup here is that we get rid of the idea of whole-translation-unit output, since that was specific to HLSL output, and there is really no strong reason for keeping it. Users should now just ask for the output for each entry point that they wanted to generate. - The biggest source of complexity for the lowering process is that it needs to produce the same AST structure as the input, to deal with the complexity of the rewriter case. That is, we need the output to be able to reproduce the input exactly in the case where we are rewriting and nothing needs to change, so the output format needs at least the degrees of freedom of the input. - As a result, we end up having to distinguish "rewriter" and "full" modes in both lowering and code-emit steps, so that we can react appropriately. - Generating a GLSL `main()` also adds a lot of complexity. Right now I'm using the simplest approach, where we always output the Slang/HLSL entry point as an ordinary function (as written) and then emit a simple GLSL `main()` to call it. I generate globals for all the shader inputs/outputs (these need to be scalarized and have explicit `location`s attached), and then collect these into the `struct` types of the original parameters as needed. - This approach will start to have some major down-sides once we have to deal with "arrayed" input/output - A long-term question here is how to replace entry-point parameter types with scalarized and/or "transposed" versions, while still letting the original code work as written (including copying those inputs to temporary arrays) - Split `BlockStatementSyntaxNode` into: - `BlockStmt` which just provides a scope around a `body` statement - `SeqStmt` which just allows multiple statements to be treated as one - Change how we emit `for` loops, to deal with the case where the initialization part might expand into multiple statements - Basically `for(A;B;C) {D}` becomes `{A; for(;B;C) {D}}`, so we can handle arbitrary statements for `A` - As an additional wrinkle, when we are rewriting HLSL, we just generate `A; for(;B;C) {D}` to deal with the broken scoping there - This change is needed because the lowering pass was sometimes expanding the original initialization statement `A` into a block `{A}`. Certainly if it declared multiple variables we'd need to handle it, and this seemed the easiest way - A more significant challenge for lowering would come if/when we ever wanted to support true short-circuiting behavior for `&&` and `||` - For right now I'm not changing the behavior of the "rewriter" mode, so we still have `UnparsedStmt` instances being generated, but it is clear that eventually we need to parse *all* input, even if we can't type-check 100% of it. This is required so that we can rewrite user code that might refer to a shader input with interface type. --- source/slang/type-layout.h | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) (limited to 'source/slang/type-layout.h') diff --git a/source/slang/type-layout.h b/source/slang/type-layout.h index 07867fddb..ce1f8864d 100644 --- a/source/slang/type-layout.h +++ b/source/slang/type-layout.h @@ -143,8 +143,13 @@ struct SimpleArrayLayoutInfo : SimpleLayoutInfo struct LayoutRulesImpl; +// Base class for things that store layout info +class Layout : public RefObject +{ +}; + // A reified reprsentation of a particular laid-out type -class TypeLayout : public RefObject +class TypeLayout : public Layout { public: // The type that was laid out @@ -215,7 +220,7 @@ enum VarLayoutFlag : VarLayoutFlags }; // A reified layout for a particular variable, field, etc. -class VarLayout : public RefObject +class VarLayout : public Layout { public: // The variable we are laying out @@ -324,7 +329,14 @@ public: // Layout information for a single shader entry point // within a program -class EntryPointLayout : public RefObject +// +// Treated as a subclass of `StructTypeLayout` becase +// it needs to include computed layout information +// for the parameters of the entry point. +// +// TODO: where to store layout info for the return +// type of the function? +class EntryPointLayout : public StructTypeLayout { public: // The corresponding function declaration @@ -332,10 +344,13 @@ public: // The shader profile that was used to compile the entry point Profile profile; + + // Layout for any results of the entry point + RefPtr resultLayout; }; // Layout information for the global scope of a program -class ProgramLayout : public RefObject +class ProgramLayout : public Layout { public: // We store a layout for the declarations at the global @@ -359,14 +374,6 @@ public: List> entryPoints; }; -// A modifier to be attached to syntax after we've computed layout -class ComputedLayoutModifier : public Modifier -{ -public: - RefPtr typeLayout; -}; - - struct LayoutRulesFamilyImpl; // A delineation of shader parameter types into fine-grained -- cgit v1.2.3