https://github.com/shader-slang/slang
- HEAD
- refs/heads/csyonghe-patch-1
- refs/heads/glsl-intrinsic-functional-test
- refs/heads/master
- refs/heads/release-debug
- refs/heads/swoods-nv-patch-1
- refs/tags/''
- refs/tags/v''
- refs/tags/v0.12.19
- refs/tags/v0.12.26
- refs/tags/v0.12.27
- refs/tags/v0.12.28
- refs/tags/v0.12.29
- refs/tags/v0.13.4
- refs/tags/v0.13.5
- refs/tags/v0.13.6
- refs/tags/v0.13.6.1
- refs/tags/v0.24.39
- refs/tags/v0.24.40
- refs/tags/v0.24.41
- refs/tags/v0.24.42
- refs/tags/v0.24.48
- refs/tags/v0.24.49
- refs/tags/v0.24.50
- refs/tags/v0.24.52
- refs/tags/v0.8.3
- refs/tags/v0.8.4
- refs/tags/v0.8.5
- refs/tags/v0.8.5-rc
- refs/tags/v0.8.6
- refs/tags/v0.8.6-rc
- refs/tags/v0.8.7
- refs/tags/v0.8.8
- refs/tags/v2023.5.5
- refs/tags/v2024.1.10
- refs/tags/v2024.1.11
- refs/tags/v2024.1.13
- refs/tags/v2024.1.15
- refs/tags/v2024.1.16
- refs/tags/v2024.1.19
- refs/tags/v2024.1.27
- refs/tags/v2024.1.28
- refs/tags/v2024.1.29
- refs/tags/v2024.1.30
- refs/tags/v2024.1.7
- refs/tags/v2024.1.9
- refs/tags/v2024.10.1-draft
- refs/tags/v2024.9
- refs/tags/v2024.9.1
- v0.18.22
- v2024.9.2
- v2024.10
- v2024.1.8
- v2024.1.6
- v2024.1.5
- v2024.1.4
- v2024.1.34
- v2024.1.33
- v2024.1.32
- v2024.1.31
- v2024.1.3
- v2024.1.26
- v2024.1.25
- v2024.1.24
- v2024.1.23
- v2024.1.22
- v2024.1.21.1
- v2024.1.21
- v2024.1.20
- v2024.1.2
- v2024.1.18
- v2024.1.17
- v2024.1.14
- v2024.1.12
- v2024.1.1
- v2024.1.0
- v2024.0.9
- v2024.0.8
- v2024.0.7
- v2024.0.6
- v2024.0.5
- v2024.0.4
- v2024.0.3
- v2024.0.2
- v2024.0.15
- v2024.0.14
- v2024.0.13
- v2024.0.12
- v2024.0.11
- v2024.0.10
- v2024.0.1
- v2024.0.0
- v2023.5.8
- v2023.5.7
- v2023.5.6
- v2023.5.4
- v2023.5.3
- v2023.5.2
- v2023.5.1
- v2023.5.0
- v2023.4.9
- v2023.4.8
- v2023.4.7
- v2023.4.6
- v2023.4.5
- v2023.4.4
- v2023.4.3
- v2023.4.2
- v2023.4.10
- v2023.4.1
- v2023.4.0
- v2023.3.9
- v2023.3.8
- v2023.3.7
- v2023.3.6
- v2023.3.5
- v2023.3.4
- v2023.3.3
- v2023.3.20
- v2023.3.2
- v2023.3.19
- v2023.3.18
- v2023.3.17
- v2023.3.16
- v2023.3.15
- v2023.3.14
- v2023.3.13
- v2023.3.12
- v2023.3.11
- v2023.3.10
- v2023.3.1
- v2023.3.0
- v2023.2.1
- v2023.2.0
- v2023.1.1
- v2023.1.0
- v2023.0.6
- v2023.0.5
- v2023.0.4
- v2023.0.3
- v2023.0.2
- v2023.0.1
- v2023.0.0
- v0.9.9
- v0.9.8
- v0.9.7
- v0.9.6
- v0.9.5
- v0.9.4
- v0.9.3
- v0.9.2
- v0.9.15
- v0.9.14
- v0.9.13
- v0.9.12
- v0.9.11
- v0.9.10
- v0.9.1
- v0.9.0
- v0.8.9
- v0.8.2
- v0.8.13
- v0.8.12
- v0.8.11
- v0.8.10
- v0.8.1
- v0.8.0
- v0.7.9
- v0.7.8
- v0.7.7
- v0.7.6
- v0.7.5
- v0.7.4
- v0.7.3
- v0.7.2
- v0.7.10
- v0.7.1
- v0.7.0
- v0.6.9
- v0.6.8
- v0.6.7
- v0.6.6
- v0.6.5
- v0.6.4
- v0.6.3
- v0.6.2
- v0.6.1
- v0.6.0
- v0.5.6
- v0.5.5
- v0.5.4
- v0.5.3
- v0.5.2
- v0.5.1
- v0.5.0
- v0.4.2
- v0.4.1
- v0.4.0
- v0.3.2
- v0.3.1
- v0.3.0
- v0.28.3
- v0.28.2
- v0.28.1
- v0.28.0
- v0.27.9
- v0.27.8
- v0.27.7
- v0.27.6
- v0.27.5
- v0.27.4
- v0.27.3
- v0.27.21
- v0.27.20
- v0.27.2
- v0.27.19
- v0.27.18
- v0.27.17
- v0.27.16
- v0.27.15
- v0.27.14
- v0.27.13
- v0.27.12
- v0.27.11
- v0.27.10
- v0.27.1
- v0.27.0
- v0.26.0
- v0.25.5
- v0.25.4
- v0.25.3
- v0.25.2
- v0.25.1
- v0.25.0
- v0.24.9
- v0.24.8
- v0.24.7
- v0.24.6
- v0.24.54
- v0.24.53
- v0.24.51
- v0.24.5
- v0.24.47
- v0.24.46
- v0.24.45
- v0.24.44
- v0.24.43
- v0.24.4-fix
- v0.24.4
- v0.24.38
- v0.24.37
- v0.24.36
- v0.24.35
- v0.24.34
- v0.24.33
- v0.24.32
- v0.24.31
- v0.24.30
- v0.24.3
- v0.24.29
- v0.24.28
- v0.24.27.1
- v0.24.27
- v0.24.26.2
- v0.24.26
- v0.24.25
- v0.24.24
- v0.24.23
- v0.24.22
- v0.24.21
- v0.24.20
- v0.24.2
- v0.24.19
- v0.24.18
- v0.24.17
- v0.24.16
- v0.24.15
- v0.24.14
- v0.24.13
- v0.24.12
- v0.24.11
- v0.24.10
- v0.24.1
- v0.24.0
- v0.23.9
- v0.23.8
- v0.23.7
- v0.23.6
- v0.23.5
- v0.23.4
- v0.23.3
- v0.23.2
- v0.23.14
- v0.23.13
- v0.23.12
- v0.23.11
- v0.23.10
- v0.23.1
- v0.23.0
- v0.22.0
- v0.21.2
- v0.21.1
- v0.21.0
- v0.20.1
- v0.20.0
- v0.2.0
- v0.19.9
- v0.19.8
- v0.19.7
- v0.19.6
- v0.19.5
- v0.19.4
- v0.19.3
- v0.19.26
- v0.19.25
- v0.19.24
- v0.19.23
- v0.19.22
- v0.19.21
- v0.19.20
- v0.19.2.1
- v0.19.2
- v0.19.19
- v0.19.18
- v0.19.17
- v0.19.16
- v0.19.15
- v0.19.14
- v0.19.13
- v0.19.12
- v0.19.11
- v0.19.10
- v0.19.1
- v0.19.0
- v0.18.9
- v0.18.8
- v0.18.7
- v0.18.6
- v0.18.5
- v0.18.4-pre
- v0.18.4
- v0.18.3
- v0.18.25
- v0.18.24
- v0.18.23
- v0.18.21
- v0.18.20
- v0.18.2
- v0.18.19
- v0.18.18
- v0.18.17
- v0.18.16
- v0.18.15
- v0.18.14
- v0.18.13
- v0.18.12
- v0.18.11
- v0.18.10
- v0.18.1
- v0.18.0
- v0.17.7
- v0.17.6
- v0.17.5
- v0.17.4
- v0.17.3
- v0.17.2
- v0.17.1
- v0.17.0
- v0.16.9
- v0.16.8
- v0.16.7
- v0.16.6
- v0.16.5
- v0.16.4
- v0.16.3
- v0.16.2
- v0.16.14
- v0.16.13
- v0.16.12
- v0.16.11
- v0.16.10
- v0.16.1
- v0.16.0
- v0.15.9
- v0.15.8
- v0.15.7
- v0.15.6
- v0.15.5
- v0.15.4
- v0.15.3
- v0.15.2
- v0.15.13
- v0.15.12
- v0.15.11.2
- v0.15.11.1
- v0.15.11
- v0.15.10
- v0.15.1
- v0.15.0
- v0.14.3
- v0.14.2
- v0.14.1
- v0.14.0
- v0.13.9
- v0.13.8
- v0.13.7
- v0.13.3
- v0.13.2
- v0.13.13
- v0.13.12
- v0.13.11
- v0.13.10
- v0.13.1
- v0.13.0
- v0.12.9
- v0.12.8
- v0.12.7
- v0.12.6
- v0.12.5
- v0.12.4
- v0.12.30
- v0.12.3
- v0.12.25
- v0.12.24
- v0.12.23
- v0.12.22
- v0.12.21
- v0.12.20
- v0.12.2
- v0.12.18
- v0.12.17
- v0.12.16
- v0.12.15
- v0.12.14
- v0.12.13
- v0.12.12
- v0.12.11
- v0.12.10
- v0.12.1
- v0.12.0
- v0.11.9
- v0.11.8
- v0.11.7
- v0.11.6
- v0.11.5
- v0.11.4
- v0.11.3
- v0.11.23
- v0.11.22
- v0.11.21
- v0.11.20
- v0.11.2
- v0.11.19
- v0.11.18
- v0.11.17
- v0.11.16
- v0.11.15
- v0.11.14
- v0.11.13
- v0.11.12
- v0.11.11
- v0.11.10
- v0.11.1
- v0.11.0
- v0.10.9
- v0.10.8
- v0.10.7
- v0.10.6
- v0.10.5
- v0.10.4
- v0.10.36
- v0.10.35
- v0.10.34
- v0.10.33
- v0.10.32
- v0.10.31
- v0.10.30
- v0.10.3
- v0.10.29
- v0.10.28-rc3
- v0.10.28-rc2
- v0.10.28-rc1
- v0.10.27
- v0.10.26
- v0.10.25
- v0.10.24
- v0.10.23
- v0.10.22
- v0.10.21
- v0.10.20
- v0.10.2
- v0.10.19
- v0.10.18
- v0.10.17
- v0.10.16
- v0.10.15
- v0.10.14
- v0.10.13
- v0.10.12
- v0.10.11
- v0.10.10
- v0.10.1
- v0.10.0
- v0.1.0
- v-test.22.6.15.1
- v-test.22.6.15.0
- v-test-220616-1
- v-test-220615-4
- v-test-220615-3
- v-test-220615-2
Take a new snapshot of a software origin
If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.
Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.![swh spinner](/static/img/swh-spinner.gif)
Processing "take a new snapshot" request ...
Permalinks
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
56e49fe | Tim Foley | 22 November 2017, 19:28:29 UTC | Fix emitting of loop attributes for HLSL pass-through (#296) Fixes #295. The code previously had a white list of attributes that it passed through, implemented in `emit.cpp` in an ad hoc fashion. The fix here is to just pass through whatever attributes the user wrote, and then let the downstream compiler diagnose if any of them are errorneous. | 22 November 2017, 19:28:29 UTC |
37315c9 | Tim Foley | 20 November 2017, 21:45:10 UTC | IR: support global variable with initializers (#294) The big change here is that the ability to contain basic blocks with instructions in them has been hoisted from `IRFunc` into a new base type `IRGlobalValueWithCode` shared with `IRGlobalVar`. The basic blocks of a global variable define initialization logic for it; they can be looked at like a function that returns the initial value. Places in the IR that used to assume functions contain all the code need to be updated, but so far I only handled the cloning step. The emit logic currently handles an initializer for a global variable by outputting its logic as a separate function, and then having the variable call that function to initialize itself. This should be cleaned up over time so that we generate an ordinary expression whenever possible. I also made the emit logic correctly label any global variable without a layout (that is, any that don't represent a shader parameter) as `static` so that the downstream HLSL compiler sees them as variables rather than parameters. | 20 November 2017, 21:45:10 UTC |
3dff5a5 | Tim Foley | 18 November 2017, 03:38:26 UTC | IR: add lowering for initializer list expressions (#290) * IR: add lowering for initializer list expressions This is relatively straightforward in the easy cases, because the front-end will have already type-checked the elements of the initializer list, and attached an appropriate type to the overall expression. Notes: - We are assuming in this code that if the user provides a "flattened" initializer list when dealing with nested aggregates, then the front-end is responsible for grouping things up apprporiately (this is not actually implemented in the front-end today). - I have only handled arrays and `struct` types here, so uses of initializer lists for anything else will fail. - I have not tried to handle the common HLSL idiom of using `{0}` as a way to default-initialize things, even when their first field is not compatible with the expression `0` - I have not implemented support for default-initializing fields/elements beyond those for which explicit initializers were provided. This can be addressed as a follow-on change. This change is one clear place where the front-end lowering logic could potentially be made much cleaner using a "destination-driven" code generation strategy. For example, given the following code ```hlsl struct A { int a0; a1; }; struct B { A b0; A b1; }; struct C { B c0; B c1; }; // ... C c = { { { 0, 1 }, {2, 3}, }, /* ... */ }; ``` Our current code generator will end up allocating local variables for 1 instance of `C`, two instances of `B`, and four instances of `C`, for over 3x the allocation that would be done by a good destination-driven code generator. Yes, later optimization passes should be able to clean up the waste, but avoiding the waste from the start should result in faster compiles and also easier debugging (since intermediate IR won't be as messy in general). * Fixup: try to appease clang compiler | 18 November 2017, 03:38:26 UTC |
ba594d0 | Tim Foley | 18 November 2017, 03:01:58 UTC | IR: Add support for `out` and `inout` parameters (#289) These were already being handled a little bit, by lowering an `out T` or `inout T` function parameter in the AST to a function parameter with type `T*` in the IR, and then emiting explicit loads/stores. The HLSL emit logic, however, couldn't tell the difference between an `out` parameter, an `inout`, or a true pointer (if we ever needed to support them...). The intention (not fully implemented) was that we'd use a hierarchy of types rooted at `PtrTypeBase`: - `PtrTypeBase` - `Ptr`: "real" pointers in the C/C++ sense - `OutTypeBase`: pointers used to represent by-reference parameter passing - `OutType`: IR level type for an `out` parameter - `InOutType`: IR level type for an `inout` or `in out` parameter Actually implementing this involved: - Adding a bit more flexibility to the `Session::getPtrType` logic to allow for creating any of the concrete types above - Making the `lower-to-ir` logic create the right type for function parameters (instead of just using `PtrType`) - Making the HLSL emit logic check for the `OutType` and `InOutType` cases rather than just `PtrType` - Changing a bunch of small places in the code so that they use `PtrTypeBase` instead of `PtrType` when they should handle any of the above cases, and also make a few places check for `OutTypeBase` instead of `PtrType` or `PtrTypeBase`, when they are really trying to capture by-reference parameters - Add a test case that uses all of the different cases we care about (without these fixes, this test case generates errors from fxc because of variables being used before being initialized, becaues parameters get declared `out` that should be `inout`). A minor point here is that we are playing a bit fast and loose right now because the IR does not actually enforce any type checks. From the standpoint of the front end, `Ptr<T>`, `Out<T>`, and `InOut<T>` are all unrelated types (each is just a `struct` declared in `core.meta.slang`), but this doesn't really matter because none of these are types our current users are explicitly using. In the IR it makes perfect sense to allow `Out<T>` or `InOut<T>` as the operand of a `load` or `store` instruction (and ditto for `getFieldAddr`, etc.) - there instructions just apply to any `PtrTypeBase`. The place where this potentially gets tricky is whether an `Out<T>` can be used where a `Ptr<T>` is expected, or vice vers (e.g., can I just pass my local variable's pointer directly to an `Out<T>` function parameter? I'm going to ignore these issues for now, since the code currently works for our test case. | 18 November 2017, 03:01:58 UTC |
54bf54b | Yong He | 18 November 2017, 02:26:21 UTC | Add support for global generic parameters (#285) * Add support for global generic parameters (In-progress work) This commit include: 1. Update Slang API to allow specification of generic type arguments in an `EntryPointRequest` 2. Add parsing of `__generic_param` construct, which becomes a GlobalGenericParamDecl, contains members of `GenericTypeConstraintDecl`. 3. Semantics checking will check whether the provided type arguments conform to the interfaces as defined by the generic parameter, and store SubtypeWitness values in the EntryPointRequest, which will be used by `specializeIRForEntryPoint` when generating final IR. 4. Add a new type of substitution - `GlobalGenericParamSubstitution` for subsittuting references to `__generic_param` decls or to its member `GenericTypeConsraintDecl` with the actual type argument or witness tables. 5. Update `IRSpecContext` to apply `GlobalGenericParamSubstitution` when specializing the IR for an EntryPointRequest. 6. Update `render-test` to take additional `type` inputs, which specifies the type arguments to substitute into the global `__generic_param` types. This commit does not include ProgramLayout specialization. * IR: pass through `[unroll]` attribute (#284) The initial lowering was adding an `IRLoopControlDecoration` to the instruction at the head of a loop, but this was getting dropped when the IR gets cloned for a particular entry point. The fix was simply to add a case for loop-control decorations to `cloneDecoration`. * fix warnings * IR: support `CompileTimeForStmt` (#286) This statement type is a bit of a hack, to support loops that *must* be unrolled. The AST-to-AST pass handles them by cloning the AST for the loop body N times, and it was easy enough to do the same thing for the IR: emit the instructions for the body N times. The only thing that requires a bit of care is that now we might see the same variable declarations multiple times, so we need to play it safe and overwrite existing entries in our map from declarations to their IR values. Of course a better answer long-term would be to do the actual unrolling in the IR. This is especially true because we might some day want to support compile-time/must-unroll loops in functions, where the loop counter comes in as a parameter (but must still be compile-time-constant at every call site). * Add support for global generic parameters (In-progress work) This commit include: 1. Update Slang API to allow specification of generic type arguments in an `EntryPointRequest` 2. Add parsing of `__generic_param` construct, which becomes a GlobalGenericParamDecl, contains members of `GenericTypeConstraintDecl`. 3. Semantics checking will check whether the provided type arguments conform to the interfaces as defined by the generic parameter, and store SubtypeWitness values in the EntryPointRequest, which will be used by `specializeIRForEntryPoint` when generating final IR. 4. Add a new type of substitution - `GlobalGenericParamSubstitution` for subsittuting references to `__generic_param` decls or to its member `GenericTypeConsraintDecl` with the actual type argument or witness tables. 5. Update `IRSpecContext` to apply `GlobalGenericParamSubstitution` when specializing the IR for an EntryPointRequest. 6. Update `render-test` to take additional `type` inputs, which specifies the type arguments to substitute into the global `__generic_param` types. progress on parameter binding * Add a more contrived test case for specializing parameter bindings * update render-test to align buffers to 256 bytes (to get rid of D3D complains on minimal buffer size). * adding one more test case for parameter binding specialization. * Cleanup according to @tfoleyNV 's suggestions. * fix a bug introduced in the cleanup | 18 November 2017, 02:26:21 UTC |
0298a04 | Tim Foley | 17 November 2017, 15:09:58 UTC | IR: support `CompileTimeForStmt` (#286) This statement type is a bit of a hack, to support loops that *must* be unrolled. The AST-to-AST pass handles them by cloning the AST for the loop body N times, and it was easy enough to do the same thing for the IR: emit the instructions for the body N times. The only thing that requires a bit of care is that now we might see the same variable declarations multiple times, so we need to play it safe and overwrite existing entries in our map from declarations to their IR values. Of course a better answer long-term would be to do the actual unrolling in the IR. This is especially true because we might some day want to support compile-time/must-unroll loops in functions, where the loop counter comes in as a parameter (but must still be compile-time-constant at every call site). | 17 November 2017, 15:09:58 UTC |
0e3d9ba | Tim Foley | 17 November 2017, 03:31:57 UTC | IR: pass through `[unroll]` attribute (#284) The initial lowering was adding an `IRLoopControlDecoration` to the instruction at the head of a loop, but this was getting dropped when the IR gets cloned for a particular entry point. The fix was simply to add a case for loop-control decorations to `cloneDecoration`. | 17 November 2017, 03:31:57 UTC |
871fbee | Tim Foley | 16 November 2017, 22:01:16 UTC | Revise type legalization so it can handle constant buffers (#282) * Revise type legalization so it can handle constant buffers The existing legalization approach with "tuples" can handle scalarizing a `struct` type with resource-type fields in it, but it had several big gaps. The most notable is that given a type that mixes uniform and resource fields, we can't just blindly scalarize things: ``` struct P { float4 a; float4 b; Texture2D t; }; cbuffer C { P gParam[8]; }; ``` The existing code was completely ignoring the declaration of `gParam` inside `C`, but even if we fixed that issue, we'd get something like: ``` cbuffer C { float4 gParam_a[8]; float4 gParam_b[8]; }; Texture2D gParam_t[8]; ``` In this case we've completely changed the layout of the uniform buffer, by switching from AOS to SOA. Even if we could get the type layout logic and the IR to agree on this, it would be a surprise to users, and "principle of least surprise" should be a big deal on a project with as many moving parts as ours. The right thing to do is to have legalization create a "stripped" version of the original type `P` and use that: ``` struct P_stripped { float4 a; float4 b; }; cbuffer C { P_stripped gParam[8]; }; Texture2D gParam_t[8]; ``` Then at a call site, this: ``` foo(gParam); ``` becomes: ``` foo(gParam, gParam_t); ``` This is exactly how the current AST-to-AST legalization handles mixed uniform and resource types, but the way it does it involves some annoying kludges: - That pass has a notion of a "tuple" similar to our legalization, but every tuple has an optional "primary" entry for all the uniform data, plus tuple elements for the resources, and a given field may be represented on one side, the other, or both. It makes the code for handling tuples very messy. - That pass does the "stripping" of types by actually marking up the AST declarations (this is okay because it is constructing a new AST as it goes), so that when they get emitted certain fields don't actually show up. That is, we fix the problem with type `P` by actually *modifying* the user's declaration of `P`. That seems out of bounds for the IR. This change fixes the problem in our IR type legalization while trying to avoid the problems of the AST-to-AST pass by using two new ideas: 1. We add a new case for `LegalType` (and `LegalVal`) that is a "pair" type, where a pair consists of both an "ordinary" type (for uniform data) and a "special" type (for resource data). E.g., after legalization, the type for `C` (which can be over-simplified to `ConstantBuffer<P>` for our purposes), will be a `LegalType::pair` where the ordinary side is `ConstantBuffer<P_stripped>` and the special side is a tuple containing the `Texture2D` field. 2. We add a new (and annoyingly hacky) AST-level type called `FilteredTupleType` which is semantically a sort of tuple type (it holds a list of elements, and the elements have their own types), but which remembers an "original type" that it was created from, and for each element remembers the field of the original type that it corresponds to. This is used to construct a type like `P_stripped` as an actual AST-level structural type. The core logic for legalizing an aggregate type had to get more complicated just because of the new pair case, so there is now a `TupleTypeBuilder` that asists with taking an aggregate type, processing its fields, and then picking the right `LegalType` representation for the result. Other smaller changes: - Made the legalization logic actually legalize `PtrType<T>`. E.g., if `T` legalizes to a tuple, we need to construct a tuple of pointer types. The same exact thing needs to be applied to arrays, and any other generic type that should "distribute over" pairs/tuples. - Made the legalization logic actually legalize `ConstantBuffer<T>` and similar. The basic idea there is if `T` maps to a pair, we wrap `ConstantBuffer<...>` around the ordinary side, and `implicitDeref` around the special side. - Removed a bunch of `#ifdef`ed-out code from the end of `ir-legalize-types.cpp`. That was code from my first attempt at legalization that failed miserably (trying to do it via local changes and a work list instead of a global rewrite pass), but it had some code I wanted to reference when writing the version that actually got checked in (should have deleted the code earlier, though). - Added a bunch of cases for `LegalType::none` (and the `LegalVal` equivalent) that helped simplify the logic fo the `pair` case by allowing me to *always* dispatch to both the "ordinary" and "special" sides, even if they might not actually be present. - Renamed `TupleType` and `TupleVal` over to `TuplePseudoType` and `TuplePseudoval` to recognize the fact that we might actually need/want *real* tuples in the type system, to go along with these fake ones (that need to be optimized away). The biggest doubt I have about this change is the whole `FilteredTupleType` thing; it seems like an obviously contrived type to add to the front-end type system that really only solves IR-level problems. A cleaner approach might have been to just add a plain old `TupleType` to the front-end type system (and initially I started with that), and then have yet another `LegalType`/`LegalVal` case that handles mapping from the fields of the original type to the numbered tuple elements. I expect we'll actually want to make that change in the future (especially if we ever add true tuples to the front-end), but for right now I let myself be swayed by the desire to have these stripped/filtered types get names that explain their provenance ("where they came from") to make our output code more debuggable. The way I've done it is probably overkill, though, and we need a much more complete effort on the readability and debuggability of our output before anything like that is worth worrying about. * Fixup: typo * Fixup: fix output of "non-mangled" names for test cases - Make sure to attach high-level decls to variables created as part of type legalization - Also, try to share more of the code between the different cases of variables - Fix up `parameter-blocks` test case that was passing `-no-mangle` but expecting mangled names in the output - Fix up `multiple-parameter-blocks` to not rely on `-no-mangle` for now, because it would lead to two global variables with the same name (need to fix that underlying issue eventually). - Also fix name generation logic so that we only use "original" names (from high-level decls) specifically when the `-no-mangle` flag is on, and otherwise use IR-level names. * Fix: handle constant buffers better in render-test - Don't request both CB and SRV usage for buffers, since that is illegal - Also, don't try to create an SRV when user requested a CB (since the required usage flag won't be there) - Record the input buffer type on the `D3DBinding` for a buffer, and use that to tell us when to bind a CB instead of SRV/UAV - Fix expected output for `cbuffer-legalize` test now that we are actually feeding it correct cbuffer dta. | 16 November 2017, 22:01:16 UTC |
1a0a7f6 | Tim Foley | 15 November 2017, 18:50:15 UTC | Various IR fixes for Falcor (#280) - Change function mangling so we use `p<parameterCount>p` instead of just `p<parameterCount>` to avoid the parameter count running into digits at the start of a mangled type name and tripping up the un-mangling logic. - We really need to step back at some point and define our mangling scheme a bit more carefully, especially if we are going to keep going down this road where un-mangling things is important for generating HLSL output. - Also allow the unmangling logic to unmangle a few more cases of generic parameters, so that it can skip over them to get to the parameter count of the underlying function. - Add a notion of an `unreachable` instruction to the IR, and emit it as the terminator (if needed) at the end of the last block for a function with a non-void return type. - This does *not* implement any logic to emit a diagnostic if the `unreachable` turns out to be potentially reachable - Fix a bug in IR specialization of generics where we can't create two different specializations of the same function, because both get registered in the same hash map With all these fixes, testing in Falcor modified to use the full Slang compiler and IR for all HLSL/Slang: - The UI and text rendering shaders yield HLSL that compiles without error; no idea if they actually *work* - The ModelViewer shaders yield HLSL, but there are some issues (looks like type legalization isn't applying to stuff inside constant buffers) | 15 November 2017, 18:50:15 UTC |
59a4c0c | Tim Foley | 14 November 2017, 19:33:36 UTC | IR: add support for `switch` statements (#278) * IR: add support for `switch` statements Fixes #273 This is just something we hadn't gotten to yet on the IR. The actual design of the instruction is unsurprising (once you take into consideration the requirement for structured control flow). A `switch` instruction takes the form: switch <condition> <breakLabel> <defaultLabel> [<caseVal> <caseLabel>]* Where `condition` is the value to switch on, `breakLabel` is the "join point" after the original `switch` statement, `defaultLabel` is where to go if the value doesn't match any case, and each pair of `caseVal` and `caseLabel` is what to do on a particular value. It is required that `caseVal` be a literal, but this isn't currently being enforced in the IR (the front-end should be making a check and constant-folding the case labels). For structured control flow, we also make the assumption that the cases are in order: cases with the same label must be grouped together, and any case that falls through to another must come right before it. Given this representation, the emit logic can reconstruct a `switch` statement with relative ease, given the machinery we already have. It makes sure to group together case values with the same label (again, assuming they are contiguous), and will insert the `default:` label in with whatever group it belongs to. Actually emitting code for a `switch` statement seems superficially simple, until you realize that a complete implementation needs to handle stuff like "Duff's Device." The current implementation makes the assumption that all `case` and `default` statements are directly nested under a `switch`, and that there is no way for control flow to enter a case except by the `switch` itself, or fall-through. In order to facilitate the grouping of cases in the IR-to-HLSL emit logic, the AST-to-IR lowering logic tries to detect cases where there are multiple `case`s in a row, and emit only a single label for them. One big/annoying gotcha is that we don't properly handle the case where a `default:` case has a non-trivial fall-throguh to another case. That seems fine for now since HLSL doesn't support fall-through anyway, but it probably needs to get detected somewhere in the Slang compiler (e.g., maybe we should add a diagnostic pass over the IR that detects target-specific problems like that and emits errors). * IR: Add support for empty statements. - Add empty statement in `lower-to-ir.cpp` - Go ahead and eliminate the statement catch-all and explicitly enumerate the cases we don't support - Fix up parser for block statements so that it doesn't leave a null statement as the body of a `{}` - Add an empty statement to one of the cases for the `switch` test, to ensure we are testing empty statements | 14 November 2017, 19:33:36 UTC |
7c4ad87 | Yong He | 14 November 2017, 02:31:40 UTC | Merge pull request #277 from csyonghe/ir-legalization IR Legalization of function parameters | 14 November 2017, 02:31:40 UTC |
38f0113 | Yong He | 13 November 2017, 23:39:44 UTC | Merge branch 'ir-legalization' of https://github.com/csyonghe/slang | 13 November 2017, 23:39:44 UTC |
fd056b0 | Yong He | 13 November 2017, 23:22:03 UTC | Legalization of function parameter types. This commit fixes issue #275 This commit includes following changes: 1. legalize function parameter IRParam instructions 2. legalize function parameter types in IRFuncType 3. legalize call sites (IRCall) with proper arguments 4. legalize local vars that has a mixed resource type. | 13 November 2017, 23:39:17 UTC |
81f295f | Yong He | 13 November 2017, 23:38:38 UTC | remove unfinished test case | 13 November 2017, 23:38:38 UTC |
3dc6c1b | Yong He | 13 November 2017, 23:37:30 UTC | fix merge bug | 13 November 2017, 23:37:30 UTC |
891c2c6 | Yong He | 13 November 2017, 23:35:22 UTC | fix merge bug | 13 November 2017, 23:35:22 UTC |
bbf58ba | Yong He | 13 November 2017, 23:26:10 UTC | Merge branch 'ir-legalization' of https://github.com/csyonghe/slang | 13 November 2017, 23:26:10 UTC |
fe22b6f | Yong He | 13 November 2017, 23:22:03 UTC | Legalization of function parameter types. This commit addresses issue #275 This commit includes following changes: 1. legalize function parameter IRParam instructions 2. legalize function parameter types in IRFuncType 3. legalize call sites (IRCall) with proper arguments 4. legalize local vars that has a mixed resource type. | 13 November 2017, 23:25:41 UTC |
57f737d | Yong He | 13 November 2017, 23:22:03 UTC | Legalization of function parameter types. This commit addresses issue #275 This commit includes following changes: 1. legalize function parameter IRParam instructions 2. legalize function parameter types in IRFuncType 3. legalize call sites (IRCall) with proper arguments 4. legalize local vars that has a mixed resource type. | 13 November 2017, 23:22:34 UTC |
c9d9424 | Tim Foley | 13 November 2017, 22:17:09 UTC | Parameter block work (#276) * Don't auto-enable IR use for compute tests The `COMPARE_COMPUTE` and `COMPARE_RENDER_COMPUTE` test fixtures were set up to always enable the `-use-ir` flag on Slang, which precludes having any tests that confirm functionality on the old non-IR path (which is still required by our main customer). This change adds the `-xslang -use-ir` flags explicitly to any compute test cases that left them out, and makes the fixture no longer add it by default. * Continue building out parameter block support The initial front-end logic for parameter blocks was already added, but they are still missing a bunch of functionality. This change addresses some of the known issues: - Bug fix: don't try to emit HLSL `register` bindings for variables that consume whole register spaces/sets - Overhaul type layout logic so that it can make decisions based on a given code generation target (currently passed in as a `TargetRequest`), which allows us to decide whether or not a parameter block should get its own register set on a per-target basis. - Always use a register space/set for Vulkan - Never use a register space/set for HLSL SM 5.0 and lower - By default, don't use register spaces/sets for HLSL output - Add a command-line flag and some "target flags" to enable register-space usage for D3D targets - Hackily add initial support for parameter blocks in the AST-to-AST path - This just blindly lowers `ParameterBlock<T>` to `T`, which shouldn't quite work - A more complete overhaul will probably need to wait until the AST-to-AST legalization is changed to use the `LegalType`s from the IR legalization pass. - Add a compute-based test case to actually run code using parameter blocks - This file runs test cases both with and without the IR | 13 November 2017, 22:17:09 UTC |
c9368fe | Tim Foley | 09 November 2017, 17:18:16 UTC | IR: Add support for break and continue statements (#272) * IR: Add support for break and continue statements The front-end is already doing the work of connecting this statements to their "parent" statement, so we just needed to build a map from the `Stmt*` to the corresponding `IRBlock*`s to use for break/continue when outputting any loop statement, and then look up in the map for the branch target when outputting a break/continue. When we get around to adding `switch` statements, the same pattern should work just fine. I also added support for `do/while` statements in IR codegen, and made sure to exercise those in one of the test cases I added. There is also an unrelated IR codegen fix for when there is a "bound subscript" on the RHS of an assignment. * IR: fix handling of do/while and continue Thanks to @csyonghe for pointing out my mistake in the earlier commit. I implemented `continue` for `do/while` loops incorrectly, branching to the head of the loop instead of the loop test. I'll try to blame this mistake on the fact that I never use `do/while` loops because I think they are awful. :) The fix for that issue wasn't too bad (see `lower-to-ir.cpp`) but it surfaces a much more serious issue: I wasn't actually implementing `continue` correctly *at all* when it comes to generating HLSL/GLSL from the IR (I can't easily make an excuse for that one). The basic issue at the heart of this is that given an input statement like: ``` for(int ii = 0; ii < N; ii = doSomething(ii)) { ... } ``` The continue clause (`ii = doSomething(ii)`) could expand into many instructions (across multiple blocks, if we inline), and there is in general no guarantee when we are done that we can package up that code as an expression and spit out a new `for` loop (the same basic argument applies to a `do { ... } while(someComplexExpression())`. So, if we assume that in general we have to generate a full *statement* for the `continue` clause, what can we emit? - We could try to "outline" the continue code into its own function, so that we can call it from an expression. That could work, but has high implementation complexity. - We could introduce additional `bool` variables for control flow, outputting something like: ``` bool useContinueBlock = false; for(;;) { if(useContinueBlock) { <CONTINUE CODE>; } useContinueBlock = true; <LOOP TEST> <LOOP BODY> } ``` This works but user might balk at the extra variable we introduce. - We could duplicate the code at each continue site. That is, we emit the loop as: ``` for(;;) { <LOOP TEST> <LOOP BODY> <CONTINUE CODE> } ``` but then whenever we'd like to emit `continue;` we instead emit `{ <CONTINUE CODE>; continue; }`. This doesn't introduce any extra variables, but it causes code duplication (limited, if we don't have too many `continue` sites, and the continue clause is small - which are the common cases). When I was initially working on the IR codegen I picked that last option just because it is what `fxc` seems to do, but I neglected to actually *implement* the special-case codegen for a `continue` instruction. This change addresses that (see `emit.cpp`). Finally, once things were fixed the `continue` test case produced the results Yong told me to expect, but it also produced a warning from the downstream HLSL compiler ("hey, your loop doesn't ever actually *loop*!"), so I reworked the test back to one that actually loops (but still tests `continue`). As a final aside in this essay of a commit message: the current IR representation of control flow uses special-case instructions for various cases of unconditional branch (and two variations on `if`), but these are not strictly necessary, and a future change will hopefully clean it up. The biggest catch in doing that is that it will require the IR->source codegen to carefully track which blocks represent which kinds of branch targets in context (e.g., you can't assume that a `continue` that nees the special handling above will appear as a distinct kind of instruction). | 09 November 2017, 17:18:16 UTC |
9a26ba8 | Yong He | 08 November 2017, 18:35:11 UTC | Merge pull request #267 from csyonghe/work Don't update generated .h file if its not changed. | 08 November 2017, 18:35:11 UTC |
da58c70 | Yong He | 08 November 2017, 17:55:08 UTC | Merge branch 'master' into work | 08 November 2017, 17:55:08 UTC |
d4aaa6c | Yong He | 08 November 2017, 17:54:52 UTC | Merge pull request #268 from csyonghe/work1 Cleanup of "support generic interface method". | 08 November 2017, 17:54:52 UTC |
f408165 | Yong He | 08 November 2017, 17:08:13 UTC | Cleanup substitution of DeclaredSubtypeWitness. Now using DeclaredSubtypeWitness::declRef to determine the proper argument index in a GenericSubstitution. | 08 November 2017, 17:08:13 UTC |
ef19b42 | Yong He | 08 November 2017, 16:09:17 UTC | Cleanup of "suport generic interface method". Add a GenericValueParamDecl case in doesGenericSignatureMatchRequirement() Return a substituted DeclaredSubtypeWitness in DeclaredSubtypeWitness::SubstituteImpl() instead of return this. | 08 November 2017, 16:09:17 UTC |
97569db | Yong He | 08 November 2017, 15:14:38 UTC | Don't update generated .h file if its not changed. This changes logic of slang-generate to detect whether the newly generated .h file is different from the existing file, and update the existing file only when the actual content has changed. This helps prevent visual studio from repetitively rebuilding the slang project due to the header file being updated on every build. | 08 November 2017, 15:14:38 UTC |
e171080 | Yong He | 08 November 2017, 02:43:39 UTC | turn on 'treat warnings as errors' (#266) | 08 November 2017, 02:43:39 UTC |
a5dfa5c | Tim Foley | 08 November 2017, 00:47:36 UTC | IR: add support for `discard` statement (#261) - Add definition of `discard` instruction - A `discard` is a terminator instruction, just like `returnVoid` - Lower `DiscardStmt` in AST to a `discard` instruction in the IR - Emit `discard` instruction as a `discard;` statement when emitting HLSL/GLSL - Add a test case using the "graphics compute" mode that tests discard. The test writes to one entry in a UAV before doing a conditional (always true at runtime) discard, and then writes to another entry; we expect to see the results of the first write, but not the second. | 08 November 2017, 00:47:36 UTC |
6e591ad | Yong He | 08 November 2017, 00:09:40 UTC | Support generic interface methods (#251) * improve diagnostic messages and prevent fatal errors from crashing the compiler. * fix top level exception catching. * spelling fix * change wording of invalidSwizzleExpr diagnostic * add speculative GenericsApp expr parsing * add new test case of cascading generics call. * Fixing bugs in compiling cascaded generic function calls. Add implementation of DeclaredSubTypeWitness::SubstituteImpl() This is not needed by the type checker, but needed by IR specialization. When input source contains cascading generic function call, the arguments to `specialize` instruction is currently represented as a substitution. The arg values of this subsittution can be a `DeclaredSubTypeWitness` when a generic function uses one of its generic parameter to specialize another generic function. When the top level generics function is being specialized, this substitution argument, which is a `DeclaredSubTypeWitness`, needs to be substituted with the witness that used to specialize the top level function in the specialized specialize instruction as well. * add a test case for cascading generic function call. * parser bug fix * fixes #255 * add test case for issue #255 * Generate missing `specialize` instruction when calling a generic method from an interface constraint. When calling a generic method via an interface, we should be generating the following ir: ... f = lookup_interface_method(...) f_s = specailize(f, declRef) ... This commit fixes this `emitFuncRef` function to emit the needed `specialize` instruction. * fixes #260 This fix follows the second apporach in the disucssion. It generated mangled name for specialized functions by appending new substitution type names to the original mangled name. * Disabling removing and re-inserting specailized functions in getSpecalizeFunc() I am not sure why it is needed, it seems HLSL and GLSL backends are generating forward declarations anyways, so the order of functions in IRModule shouldn't matter. * cleanup and complete test cases. * fix warnings | 08 November 2017, 00:09:40 UTC |
939688e | Tim Foley | 07 November 2017, 22:05:22 UTC | Add reflection API to get type name (#263) This is currently only useful for `struct` types. I implemented a special-case exception so that the auto-generated `struct` types used for `cbuffer` members don't show their internal name. I did *not* implement any logic to avoid returning the name `vector` for a vector type, etc., since they are all `DeclRefType`s and it seemed easiest to just let the user access information they can't really use. | 07 November 2017, 22:05:22 UTC |
417c9f3 | Yong He | 07 November 2017, 21:55:08 UTC | Merge pull request #256 from tfoleyNV/falcor-integration-work Falcor integration work | 07 November 2017, 21:55:08 UTC |
a543643 | Tim Foley | 07 November 2017, 19:57:58 UTC | Merge branch 'master' into falcor-integration-work | 07 November 2017, 19:57:58 UTC |
d1b45f3 | Tim Foley | 07 November 2017, 19:57:48 UTC | IR: support for select and negate (#257) - During IR emit, treat a "select" expression (`?:` operator) like any other `InvokeExpr`, since it will have an `__intrinsic_op` modifier attached to turn it into a `select` instruction. - During HLSL/GLSL emit from IR, turn a `select` instruction into a `?:` expression - Also add support for the `neg` instruction during HLSL/GLSL emit Note that right now we are assuming HLSL semantics for `?:` where it does not short-circuit. Correctly handling the GLSL case would require going back to special-case codegen for `SelectExpr`, but we can cross that bridge when we come to it. | 07 November 2017, 19:57:48 UTC |
ccea570 | Tim Foley | 07 November 2017, 18:22:53 UTC | Emit pointer-type parameters as out params The IR encodes `out` and `in out` function parameters as pointer types, so the emit logic needs to handle it. We had code to handle translation of pointers types into `out` declarations for function *declarations* but weren't handling it for function *definitions*. This change unifies the logic so that it is shared by function definitions and decalrations. This change does *not* deal with the following issues that need to be addressed sometime soon-ish: - We currently always translate pointers into `out`, even if they should be `in out`. This is obviously wrong. - If/when we eventually have targets that support true pointers (e.g., CUDA, NVIDIA OpenGL, etc.) we'll need a way to tell the difference between an `in` pointer parameter, and an `out` parameter. Both of these issues are meant to be addressed by having a few special cases of pointer types, for the `out` and `in out` cases, and only translating those (not all pointers). We need to plumb those through the IR more completely, but I'm not dealing with that here. | 07 November 2017, 19:00:02 UTC |
ed29b29 | Tim Foley | 07 November 2017, 18:09:16 UTC | Fix expected output for loop test now that barrier isn't an intrinsic The test case had previously been calling `GroupBarrierWithGroupSync` as if it was a special-cased instruction, but now it is just calling it as an ordinary (intrinsic) function. I haven't removed the now-useless instruction, but it would be a good cleanup to go through and eliminate all the instruction cases we aren't using in the near future. | 07 November 2017, 18:58:59 UTC |
f4c4f63 | Tim Foley | 07 November 2017, 18:02:10 UTC | Fix for emitting subscript calls in HLSL/GLSL The old approach was relying on an `__intrinsic_op` modifier to tell us we need to do something special with an `InvokeExpr`, but a previous change removed a bunch of those modifiers. Instead, we will now check for calls to subscript declarations as part of the normal flow of emitting *any* call, similar to what is done for constructor calls already. Eventually we should be able to eliminate the special case in the `__intrinsic_op` path, but I'm holding off on that because the AST emit logic can probably be cleaned up a *lot* once it doesn't have to be used for cross-compilation as well. | 07 November 2017, 18:56:45 UTC |
97a1a95 | Tim Foley | 07 November 2017, 17:55:53 UTC | Try to fix up IR emit for subscript calls This code isn't especially useful right now since most of the important subscripts are still special-cased with `__intrinsic_op`, but the idea is that if we de-mangle an intrinsic operation's name and see it is called `operator[]` then we are probably calling a subscript, and should emit an appropriate expression. Aside: this change has pointed out to me that our current name mangling isn't properly handling non-alphanumeric characters, so we'll be in trouble as soon as we have non-intrinsic subscripts, operators, etc. | 07 November 2017, 18:54:47 UTC |
722105f | Tim Foley | 07 November 2017, 17:45:08 UTC | Add a comparison operator to UnownedStringSlice This is to allow me to compare for particular names in my de-mangling logic in `emit.cpp`. | 07 November 2017, 18:54:06 UTC |
5c22029 | Tim Foley | 07 November 2017, 17:25:41 UTC | Fixes for name mangling/demangling The source of a lot of these changes is that our current strategy for dealing with "builtin" operations when emitting HLSL from the IR is to de-mangle the mangled name of an operation, and then emit HLSL code for a function call to an operation with that de-mangled name. This change introduces a few fixups for that work: - It adds support for parsing the mangled names of generics (specialized and unspecialized) - It adds logic for detecting when the operation being invoked is a member function - This is currently a bit ugly, since we compare the number of actual arguments we have in the IR against the number of parameters declared for the callee, and if they don't match we assume we have an extra `this` argument. On the mangling side, we add (hacky) support for mangling a function name when its types involve generic parameters, e.g.: ``` __generic<T, let N : int> T length(vector<T,N> v); ``` In this case the mangled name of the function needs to include a mangling for the type `vector<T,N>` which means it also needs to include a mangling for `N`. The reason I describe this support as "hacky" is because we really shouldn't be reproducing the names `T` or `N` in the mangled symbol name. By doing so we make it so that a user changing the name of a generic parameter would break (IR) binary compatibility with existing code that was separately compiled. I've included comments in the code about a better way to handle this, but it isn't a priorit right now since binary compatibility isn't something meaningful until we start emitting usable bytecode modules. | 07 November 2017, 18:48:17 UTC |
93a444f | Tim Foley | 07 November 2017, 17:38:32 UTC | Attach correct types to subscript accessors Subscript declarations can have nested "accessor" declarations for the get/set behavior: ``` __subscript(int index) -> float { get { ... } set { ... } } ``` The AST type checks an expression like `a[i]` into a call to an appropriate `__subscript` declaration, and reads the return type off of that, but doesn't drill down to the individual getters/setters. During IR code generation, we need to resolve a call to the subscript operation down to the actual getter or setter, since those are what will have the executable code (or be intrinsics). If we have a non-intrinsic accessor, then we end up asking for its "return type" and get NULL, which crashes the compiler. The fix in this case is to add a bit more semantic checking for accessors, mostly just so that we can have them copy the return type from their parent declaration. While we are at it, this change goes ahead and has an accessor validate that the parent declaration is one that should be allowed, and emit a diagnostic if it is nested in an improper place. | 07 November 2017, 18:44:07 UTC |
9640df0 | Tim Foley | 07 November 2017, 16:31:06 UTC | Handle "ThisType" subsitutions when specialization generics in the IR The original code is handling the issue where a call site might be specializing a generic function, so it has a `DeclRef` that represents what it wants to specialize, but the callee is actually a different overload of the same generic function (e.g., a target-specific overload) and so we need to construct a set of substitutions that are equivalent (same arguments), but point to different `GenericDecl`s. That code was making some bad assumptions, though: 1. It assumed that the substitutions list would always start with a generic substitution (no longer true with `ThisTypeSubstitution`. 2. It assumed that only the top-most substitution would need to be translated. This assumption is probably safe for now, but it could break down if we ever introduced an ability for a type to be re-opened to introduce new (target-specific) overloads of its members. The new approach goes ahead and does a deep copy of the substitition list (but a shallow copy of the arguments), and only copies the generic substititions for now. | 07 November 2017, 18:40:04 UTC |
19c7c37 | Tim Foley | 06 November 2017, 22:05:32 UTC | Remove `__intrinsic_op` from many decls This attribute used to be how we marked ops for special handling in emission, but now it is being used to mark ops that map to single instructions. Either way, we have a bunch of intrinsic functions that need to get lowered in a more traditional fashion for HLSL, and the intrinsics are getting in the way. Subsequent changes will fix up issues created by this removal. A few cases were left unchanged, either because the ops really do map to single instructions, or because there is some special-case support attached to those operations that would be tricky to replace right now. | 07 November 2017, 18:38:56 UTC |
9919c82 | Tim Foley | 06 November 2017, 18:37:27 UTC | Parameter blocks (#245) * Rename existing ParameterBlock to ParameterGroup We are planning to add a new `ParameterBlock<T>` type, which maps to the notion of a "parameter block" as used in the Spire research work. Unfortunately, the compiler codebase already uses the term `ParameterBlock` as catch-all to encompass all of HLSL `cbuffer`/`tbuffer` and GLSL `uniform`/`buffer`/`in`/`out` blocks (all of which are lexical `{}`-enclosed blocks that define parameters...). This change instead renames all of the existing concepts over to `ParameterGroup`, which isn't an ideal name, but at least doesn't directly overlap the new terminology or any existing terminology. The new `ParameterBlockType` case will probably be a subclass of `ParameterGroupType`, since it is a logical extension of the underlying concept. * Add Shader Model 5.1 profiles The HLSL `register(..., space0)` syntax is only allowed on "SM5.1" and later profiles (which is supported by the newer version of `d3dcompiler_47.dll` that comes with the Win10 SDK, but not the older version of `d3dcompiler_47.dll` - good luck figuring out which you have!). This change adds those profiles to our master list of profiles, and nothing else. * First pass at support for `ParameterBlock<T>` - Add the type declaration in stdlib - Add a special case of `ParameterGroupType` for parameter blocks - Handle parameter blocks in type layout (currently handling them identically to constant buffers for now, which isn't going to be right in the long term) - Add an IR pass that basically replaces `ParameterBlock<T>` with `T` - Eventually this should replace it with either `T` or `ConstantBuffer<T>`, depending on whether the layout that was computed required a constant buffer to hold any "free" uniforms - Add first stab at an IR pass to "scalarize" global variables using aggregate types with resources inside. - This currently only applies to global variables, so it won't handle things passed through functions, or used as local variables - It also only supports cases where the references to the original variable are always references to its fields, and not the whole value itself - Add a single test case that technically passes with this level of support, but probably isn't very representative of what we need from the feature * Fold parameter-block desugaring into a more complete "type legalization" pass The basic problem that was arising is that once you desugar `ParameterBlock<T>` into `T`, you then need todeal with splitting `T` into its constituent fields if it contains any resource types. Handling those transformations by following the usual use-def chains wasn't really helping, because you might need systematic rewriting that can really only be handled bottom-up. This change adds a new pass that is intended to perform multiple kinds of type "legalization" at once: - It will turn `ParameterBlock<T>` into `T` - It may at some point also convert `ConstantBuffer<T>` into `T` as well - It will turn an value of an aggregate type that contains resources into N different values (one per field) - As a result of this, it will also deal with AOS-to-SOA conversion of these types Legalization is applied to *every* function/instruction/value, so that it can make large-scale changes that would be tough to manage with a work list. This pass needs to be run *after* generics have been fully specialized, so that we know we are always dealing with fully concrete types, so that their legalization for a given target is completely known. This is still work in progress; there's more to be done to get this working with all our test cases, and finish the remaining `ParameterBlock<T>` work. * Improve binding/layout information when using parameter blocks - When doing type layout for a parameter block, don't include the resources consumed by the element type in the resource usage for the parameter block - Note that this is pretty much identical to how a `ConstantBuffer<T>` does not report any `LayoutResourceKind::Uniform` usage, except that `ParameterBlock<T>` is *also* going to hide underlying texture/sampler reigster usage - The one exception here is that any nested items that use up entire `space`s or `set`s those need to be exposed in the resource usage of the parent (I don't have a test for this) - When type legalization needs to scalarize things, it must propagate layout information down to the new leaf variables. In general, the register/index for a new leaf parameter should be the sum of the offsets for all of the parent variables along the "chain" from the original variable down to the leaf (we aren't dealing with arrays here just yet). - When type legalization decides to eliminate a pointer(-like) type (e.g., desugar `ParameterBlock<T>` over to `T`), actually deal with that in terms of the `LegalVal`s created, so that we can know to turn a `load` into a no-op when applied to a value that got indirection removed. - Hack up the "complex" parameter-block test so that it actually passes (the big hack here is that the HLSL baseline is using names that are generated by the IR, and are unlikely to be stable as we add/remove transformations). - Note: I can't make these be compute tests right now, because regsiter spaces/sets are a feature of D3D12/Vulkan, and our test runner isn't using those APIs. | 06 November 2017, 18:37:27 UTC |
296e89c | Yong He | 05 November 2017, 21:39:38 UTC | Merge pull request #243 from csyonghe/master Adding associated types | 05 November 2017, 21:39:38 UTC |
ff7c46a | Yong He | 05 November 2017, 10:49:42 UTC | small cleanups | 05 November 2017, 10:49:42 UTC |
0d250f0 | Yong He | 05 November 2017, 00:21:19 UTC | style fixes | 05 November 2017, 00:21:19 UTC |
6e4ba9b | Yong He | 05 November 2017, 00:07:47 UTC | naming cleanup | 05 November 2017, 00:07:47 UTC |
87c15d3 | Yong He | 04 November 2017, 23:41:31 UTC | move advanced test cases out of 'smoke' category | 04 November 2017, 23:41:31 UTC |
33d9f07 | Yong He | 04 November 2017, 23:19:23 UTC | cleanup useless code | 04 November 2017, 23:19:23 UTC |
aeb69cb | Yong He | 04 November 2017, 23:12:01 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 04 November 2017, 23:12:01 UTC |
c6fb1de | Yong He | 04 November 2017, 23:11:37 UTC | fixed last couple warnings under release/x64 build. | 04 November 2017, 23:11:37 UTC |
8c0a429 | Yong He | 04 November 2017, 22:45:42 UTC | fix warnings | 04 November 2017, 22:45:42 UTC |
a4fabfc | Yong He | 04 November 2017, 22:43:26 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 04 November 2017, 22:43:26 UTC |
215ce20 | Yong He | 04 November 2017, 22:43:03 UTC | fixes x64 warnings | 04 November 2017, 22:43:03 UTC |
00e0382 | Yong He | 04 November 2017, 22:07:26 UTC | merge | 04 November 2017, 22:07:26 UTC |
d1009d1 | Yong He | 04 November 2017, 22:07:09 UTC | merge with fixWarnings branch | 04 November 2017, 22:07:09 UTC |
1f9686c | Yong He | 04 November 2017, 21:03:00 UTC | determineEncoding bug fix | 04 November 2017, 21:03:00 UTC |
cb0a577 | Yong He | 04 November 2017, 20:54:44 UTC | bug fix | 04 November 2017, 20:54:44 UTC |
784bd91 | Yong He | 04 November 2017, 20:30:18 UTC | fix linux build | 04 November 2017, 20:30:18 UTC |
98d2f27 | Yong He | 04 November 2017, 20:27:50 UTC | gcc warning fix | 04 November 2017, 20:27:50 UTC |
a7dd782 | Yong He | 04 November 2017, 20:23:21 UTC | fix linux build | 04 November 2017, 20:23:21 UTC |
8d19b2b | Yong He | 04 November 2017, 20:15:15 UTC | Merge branch 'master' of https://github.com/shader-slang/slang | 04 November 2017, 20:15:15 UTC |
288841f | Yong He | 04 November 2017, 20:09:48 UTC | fixed all warnings | 04 November 2017, 20:09:48 UTC |
664e0da | Yong He | 04 November 2017, 19:37:40 UTC | fix all unreachable code warnings | 04 November 2017, 19:37:40 UTC |
31e7f84 | Yong He | 04 November 2017, 19:20:21 UTC | Passing both assoctype-simple and assoctype-complex test cases. | 04 November 2017, 19:20:21 UTC |
d803bf7 | Yong He | 04 November 2017, 19:19:24 UTC | enable -use-ir option when executing compute test cases. | 04 November 2017, 19:19:24 UTC |
0ed248a | Yong He | 04 November 2017, 19:17:57 UTC | Natvis file update for improved debugging view of IR constructs | 04 November 2017, 19:17:57 UTC |
3d90678 | Yong He | 04 November 2017, 19:17:08 UTC | Fix encoding detection when reading text file. Win32 API could mistakenly report UTF16 when the file is actually UTF8. | 04 November 2017, 19:17:08 UTC |
ba396cc | Yong He | 04 November 2017, 10:59:12 UTC | Merge https://github.com/shader-slang/slang | 04 November 2017, 10:59:12 UTC |
76db363 | Yong He | 04 November 2017, 10:57:48 UTC | work in-progress | 04 November 2017, 10:57:48 UTC |
0a36567 | Yong He | 03 November 2017, 22:55:03 UTC | associatedtypes: generating almost correct HLSL, but is not calling correctly mangled function. | 03 November 2017, 22:55:03 UTC |
cc98fd4 | Tim Foley | 03 November 2017, 19:25:46 UTC | Fix #248 (#249) * Fix up test runner output for compute. We want compute-based tests to produce a `.actual` file when compilation fails, so we can easily diagnose the issue. I thought I'd added this capability previous, but it seemst to not be present any more. * Compute result types for constructor decls Fixes #246 When the parser sees an `init()` declaration, it can't easily know what type is is supposed to return, so it leaves the type as NULL. This was causing some downstream crashes. Rather than special-case every site that cares about the result type of a callable, we will instead ensure that we install an actual result type on an initializer/constructor as part of its semantic checking. This code needs to handle both the case where the initializer is declared inside a type, as well as the case where it is declared inside an `extension`. | 03 November 2017, 19:25:46 UTC |
38ec0e0 | Yong He | 03 November 2017, 13:45:54 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 03 November 2017, 13:45:54 UTC |
8fe947b | Yong He | 03 November 2017, 13:42:44 UTC | Update natvis file for better viewing of RefPtr, DeclRef and Name classes | 03 November 2017, 13:42:44 UTC |
a045826 | Yong He | 03 November 2017, 13:38:02 UTC | in-progress work | 03 November 2017, 13:38:02 UTC |
d5e2319 | YONGH\yongh | 02 November 2017, 23:21:15 UTC | work inprogress | 02 November 2017, 23:21:15 UTC |
e2b9760 | YONGH\yongh | 01 November 2017, 18:05:33 UTC | remove assoctype-complex case to get pass test | 01 November 2017, 18:05:33 UTC |
134354c | Yong He | 01 November 2017, 17:16:26 UTC | Adding support for associated types. | 01 November 2017, 17:16:26 UTC |
b623864 | Yong He | 01 November 2017, 17:00:29 UTC | Merge https://github.com/shader-slang/slang | 01 November 2017, 17:00:29 UTC |
ec41631 | Tim Foley | 01 November 2017, 15:30:45 UTC | Allow use of dxc compiler for DXIL generation (#241) - Add shader model 6.0, 6.1, and 6.2 targets - Add DXIL and DXIL assembly as output formats - Add header for DXC API to `external/` - Add `dxc-support.cpp` that wraps usage of the API - Add `-pass-through dxc` option, equivalent to what we have for `fxc` Notes: * This does *not* include any logic to add `dxcompiler.dll` to our build process; that is way out of scope for the build complexity I'm ready to deal with * For right now, the use of `dxcompiler.dll` is hard-coded, and it must be discoverable in the current executable's search path; options to customize can come later * The `-pass-through` option is kind of silly because the code doesn't actually pay attention to the value (just whether it is set). If you set it to `fxc` but ask for DXIL, we pass through `dxc` anyway. | 01 November 2017, 15:30:45 UTC |
b475415 | Yong He | 31 October 2017, 15:13:00 UTC | merge | 31 October 2017, 15:13:00 UTC |
093bf1e | Yong He | 31 October 2017, 15:12:08 UTC | work in-progress: type checking associated types | 31 October 2017, 15:12:08 UTC |
e2b4730 | Yong He | 31 October 2017, 10:28:23 UTC | Merge pull request #240 from csyonghe/master Fixing issue #236 | 31 October 2017, 10:28:23 UTC |
8ba5d28 | Yong He | 31 October 2017, 09:56:28 UTC | initiate rebuild | 31 October 2017, 09:56:28 UTC |
436c906 | Yong He | 31 October 2017, 08:26:06 UTC | Revert "work in-progress, add parsing for assoc type decls and member type expressions" This reverts commit 84f381cc180b3176d6a58da4085ee8470f246922. | 31 October 2017, 08:26:06 UTC |
84f381c | YONGH\yongh | 31 October 2017, 01:18:20 UTC | work in-progress, add parsing for assoc type decls and member type expressions | 31 October 2017, 01:18:20 UTC |
91ac155 | YONGH\yongh | 30 October 2017, 23:40:13 UTC | Fixing issue #236 | 30 October 2017, 23:40:13 UTC |
832d9c7 | Yong He | 30 October 2017, 23:31:52 UTC | Merge pull request #235 from tfoleyNV/explicit-this-expr Support `this` expressions (explicit and implicit) | 30 October 2017, 23:31:52 UTC |
3ffdf61 | Tim Foley | 30 October 2017, 20:47:04 UTC | Merge branch 'master' into explicit-this-expr | 30 October 2017, 20:47:04 UTC |
c24c173 | Tim Foley | 30 October 2017, 18:17:20 UTC | Fix output for type cast when checking fails (#238) There were some cases where we would try to emit an `ErrorType` to the output HLSL, which obviously isn't allowed. This change tries to avoid emitting error types, and instead use the original expression when it is available. I tried adding a test case for the change, but I can't convince Slang to output matching line numbers for the error message; it seems like more work is needed on that front. | 30 October 2017, 18:17:20 UTC |
11f4424 | Tim Foley | 30 October 2017, 17:03:52 UTC | Allow for implicit `this` expressions. - When peforming ordinary lookup, if the container declaration for a scope is an aggregate type or `extension` decl, then use a "breadcrumb" to make sure that we use a `this` expression as the base of any resulting declaration reference - Add a test case for implicit `this` usage - Update constrained generic test case to use implicit `this` for member reference, as was originally intended | 30 October 2017, 17:26:22 UTC |
42f1cff | Tim Foley | 30 October 2017, 15:54:09 UTC | Support explicit `this` expressions This is the first step towards supporting traditional object-oriented method definitions; the second step will be to allow `this` expressions to be implicit. - Add a test case using explicit `this`, and expected output - Update parsing logic for expressions so that it handled identifiers similarly to the declaration and statement logic: first try to parse using a syntax declaration looked up in the curent scope, and otherwise fall back to the ordinary `VarExpr` case. * As long as I'm making that change: switch `true` and `false` to be parsed via the callback mechanism rather than be special-cased. * This change will also help out if we ever wanted to add `super`/`base` expressions, `new`, `sizeof`/`alignof` or any other expression keywords. - Add a `ThisExpr` node and register a parser callback for it. - Add semantic checks for `ThisExpr`: basically just look upwards through scopes until we find either an aggregate type declaration or an `extension` declaration, and then use that as the type of the expression. - TODO: eventually we need to guard against a `this` expression inside of a `static` member. - The IR generation logic already handled creation of `this` parameters in function signatures; the missing piece was to register the appropriate parameter in the context, so that we can use it as the lowering of a `this` expression. | 30 October 2017, 16:40:04 UTC |
4ab545b | Tim Foley | 27 October 2017, 18:22:11 UTC | Initial work on support code generation for generics with constraints (#233) This change includes a lot of infrastructure work, but the main point is to allow code like the following: ``` // define an interface interface Helper { float help(); } // define a generic function that uses the interface float test<T : Helper>( T t ) { return t.help(); } // define a type that implements the interface struct A : Helper { float help() { return 1.0 } } // define an ordinary function that calls the // generic function with a concrete type: float doIt() { A a; return test<A>(a); } ``` Getting this to generate valid code involves a lot of steps. This change includes the initial version of all of these steps, but leaves a lot of gaps where more complete implementation is required. The changes include: - Member lookup on types has been centralized, and now handles the case where the type we are looking for a member in is a generic parameter (e.g., given `t.help()` we can now look up `help` in `Helper` by knowing that `t` is a `T` and `T` conforms to `Helper`). - There is an obvious cleanup still to be done here where the same exact logic should be used to look up available "constructor" declarations inside a type when the type is used like a function. - Add a notion of subtype constraint "wittnesses" to the type system. When a generic is declared as taking `<T : Helper>` it really takes two generic parameters: the type `T` and a proof that `T` conforms to `Helper`. The actual arguments to a generic will then include both the type argument and a suitable witness argument (both type-level values). - As it stands right now, a witness wraps a `DeclRef` to the declaration that represents the appropriate subtype relationship. So if we have `struct A : Helper`, that `: Helper` part turns into an `InheritanceDecl` member, and a reference to that member can serve as a witness to the fact that `A` conforms to `Helper`. - Make explicit generic application `G<A,B>` synthesize the additional arguments that represent conformances required by the generic. - This does *not* yet deal with the case where a generic is implicitly specialized as part of an ordinary call `G(a,b)` - A bug fix to not auto-specialize generics during lookup. The problem here was related to an attempted fix of an earlier issue. During checking of a method nested in a generic type, we were running into problems where `DeclRefType::create()` was getting called on an un-specialized reference to `vector`, and this was leading to a crash when the code looked for the arguments for the generic. This was worked around by having name lookup automatically specialize any generics it runs into while going through lookup contexts. That choice creates the problem that in a generic method like this: ``` void test<T>(T val) { ... } ``` any reference to `val` inside the body of `test` will end up getting specialized so that it is effectively `test<T>::val`, when that isn't really needed. - Add front-end logic to check that when a type claims to conform to an interface it actually must provide the methods required by the interface. The checking process goes ahead and builds a front-end "witness table" that maps declarations in the interface being conformed to over to their concrete implementations for the type. - At the moment the checking is completely broken and bad: it assumes that *any* member with the right name is an appropriate declaration to satisfy a requirement. That obviously needs to be fixed. - Add an explicit operation to the IR for lookup of methods: `lookup_interface_method(w, r)` where `w` is a reference to the "witness" value and `r` is an `IRDeclRef` for the member we want to look up. - Add an explicit notion of witness tables to the IR. These end up being the IR representation of an `InheritanceDecl` in a type, and they are generated by enumerating the members that satisfy the interface requirements (which were handily already enumerated by the front-end checking). The witness table is an explicit IR value, and so it will be referenced/used at the site where conformance is being exploited (e.g., as part of a `specialize` call), so it should be safe to eliminate witness tables that are unused (since they represent conformances that aren't actually exploited). Similarly, the entries in a witness table are uses of the functions that implement interface methods, and so keep those live. - In order to implement the above, I did a bit of a cleanup pass on the IR representation so that there is an `IRUser` base that `IRInst` inherits from, so that we can have users of values that aren't instructions. - One annoying thing is that because of how types and generics are handled in the IR, we needed a way to have a type-level `Val` that wraps an IR-level value: e.g., to allow an IR-level witness table to be used as one of the arguments for specialization of a generic. The design I chose here is to have a "proxy" `Val` subclass (`IRProxyVal`) that wraps an `IRValue*`. These should only ever appear as part of types and `DeclRef`s that are used by the IR. - One annoying bit here is that an IR value might then have a use that is not manifest in the set of IR instructions, and instead only appears as part of a type somewhere. - I'm not 100% happy with this design, but it seems like we'd have to tackle similar issues if/when we eventually allow functions to have `constexpr` or `@Constant` parameters - Make generic specialization also propagate witness table arguments through to their use sites (this is mostly just the existing substitution machinery, once we have `IRProxyVal`), and then include logic to specialize `lookup_interface_method` instructions when their first operand is a concrete witness table. All of this work allows a single limited test using generics with constraints to pass, but more work is needed to make the solution robust. | 27 October 2017, 18:22:11 UTC |
56bc826 | Yong He | 26 October 2017, 03:16:53 UTC | Merge pull request #230 from csyonghe/master Finish up implementation of render-test | 26 October 2017, 03:16:53 UTC |
3a7dcf6 | YONGH\yongh | 26 October 2017, 02:58:24 UTC | ignore RENDER_COMPUTE test cases in linux build. | 26 October 2017, 02:58:24 UTC |
1981c92 | YONGH\yongh | 26 October 2017, 02:23:02 UTC | render-test code cleanup | 26 October 2017, 02:23:02 UTC |
14d93b0 | YONGH\yongh | 26 October 2017, 02:13:11 UTC | fix d3d11 usage | 26 October 2017, 02:13:11 UTC |
9a28965 | YONGH\yongh | 26 October 2017, 01:44:42 UTC | test | 26 October 2017, 01:44:42 UTC |
9a120fc | YONGH\yongh | 26 October 2017, 01:32:28 UTC | test | 26 October 2017, 01:32:28 UTC |