Skip to main content

Browse the archive

https://github.com/shader-slang/slang
06 April 2024, 09:30:39 UTC
sort by:
Revision Author Date Message Commit Date
372900b Tim Foley 27 February 2018, 00:28:24 UTC Add GLSL translations for bit manipulation intrinsics (#430) The following translations are added: * HLSL `countbits` becomes GLSL `bitCount` * HLSL `firstbitlow` becomes GLSL `findLSB` * HLSL `firstbithight` becomes GLSL `findMSB` * HLSL `rerverseBits` becomes GLSL `bitfieldReverse` There are currently no HLSL equivalents for the bitfield insert/extract operations in GLSL. In the future we could expose those as intrinsics under their GLSL names, with HLSL translations, if desired. 27 February 2018, 00:28:24 UTC
c3bc496 Tim Foley 26 February 2018, 22:02:29 UTC Merge from 0.9.x (#429) * Fix bug when subscripting a type that must be split (#396) The logic was creating a `PairPseudoExpr` as part of a subscript (`operator[]`) operation, but neglecting to fill in its `pairInfo` field, which led to a null-pointer crash further along. * Allow writes to UAV textures (#416) Work on #415 This issue is already fixed in the `v0.10.*` line, but I'm back-porting the fix to `v0.9.*`. The issue here was that the stdlib declarations for texture types were only including the `get` accessor for subscript operations, even if the texture was write-able. I've also included the fixes for other subscript accessors in the stdlib (notably that `OutputPatch<T>` is readable, but not writable, despite what the name seems to imply). * Fix infinite loop in semantic parsing (#424) The code for parsing semantics was looking for a fixed set of tokens to terminate a semantic list, rather than assuming that whenever you don't see a `:` ahead, you probably are done with semantics. This meant that you could get into an infinite loop just with simple mistakes like leaving out a `;`. This change fixes the parser to note infinite loop in this case, and adds a test case to verify the fix. 26 February 2018, 22:02:29 UTC
28887ae Tim Foley 26 February 2018, 20:14:24 UTC Fix GS stream types (#428) The code in `DeclRefType::Create` was treating all of the point/line/triangle output stream types as `HLSLPointStreamType`, which meant we always output GLSL geometry shaders with `layout(points) out;`. 26 February 2018, 20:14:24 UTC
b942849 Yong He 23 February 2018, 23:32:43 UTC Merge pull request #426 from csyonghe/irtypesstep0 Refactor IR type system, step 0 23 February 2018, 23:32:43 UTC
5ab20eb Yong He 23 February 2018, 22:22:36 UTC Refactor IR type system, step 0 Pull BaseType, TextureFlavor and SamplerStateFlavor enums and helper functions into a shared file "type-system-shared.h". 23 February 2018, 22:41:46 UTC
7066759 Tim Foley 23 February 2018, 18:39:23 UTC Initial support for cross-compilation of geometry shaders to GLSL (#423) These changes are related to getting a first Slang geometry shader to translate to GLSL. There are some unrelated cross-compilation fixes in here as well. * Add direct support to shader parameter layout for GS output streams, so that they are reflected as a container type * Fix the declarations of the `SampleCmp` methods; they should always return `float`, independent of the nominal element type of the texture. * Fix up our handling of `__target_intrinsic` modifiers, so that we are a little bit more careful in how we detect something as being just a simple name replacement (e.g., `__target_intrinsic(glsl, "foo")` should make us output `foo(original, args, here)`) vs. a custom expression (e.g., `__target_intrinsic(glsl, "bar+1")` should output `bar+1` and not use any arguments, even without any `$` substitutions). * Don't emit the `[unroll]` modifier when outputting GLSL. Eventually we need to fully unroll loops for GLSL output anyway. * Inspect th entry point parameter list (from the layout information) when emitting a GS, so that we can write out the correct `layout` modifiers for input primitive type and output primitive topology. * Add a new case to `ScalarizedVal` to handle cases where an HLSL system value needs to map to a GLSL built-in variable with a slightly different type (e.g., `SV_RenderTargetArrayIndex` is a `uint` while `gl_Layer` is an `int`). For now this is only hanlding trivial cases (where a direct cast can achieve the result we want), but eventually it might need to handle things like conversion between arrays and vectors. * This is mostly just the infrastructure for the feature, and the actual enumeration of the correct types for all the system values is still to be done. * Handle a few more cases in assignment between `ScalarizedVal`. In particular, deal with cases where `materializeValue` is called on a tuple that has an array type, so that we need to construct the individual array elements. * Add translation for GS output stream `Append()` and `RestartStrip()` * Note that the translation of `Append()` seems to ignore its argument; this is because we desugar the operation during legalization for GLSL (see next item) * When legalizing for GLSL, detect an entry point parameter that is a GS stream, and translate it into `out` variables for its element type, and then rewrite any calls to `Append()` in the body of the entry point to be preceded by assignment to those variables. This works in tandem with the above translation of HLSL `Append()` calls into GLSL `EmitVertex()` calls. * We are detecting calls to `Append()` in a slightly hacky way, by looking at decorations on the callee to make sure that it is a function that is determined to translate to `EmitVertex()`. * Right now we aren't handling calls to `Append()` in other functions. It wouldn't be hard in principle to walk all the functions in the module and apply the translation (assuming we don't want to start supporting multiple output streams), but this wouldn't handle the passing of the GS output stream between functions. (This points out that there is a need for an additional type legalization pass that desugars away parameters of types that aren't actually meaningful on the target). 23 February 2018, 18:39:23 UTC
42c3a7c Yong He 22 February 2018, 20:35:11 UTC Merge pull request #422 from csyonghe/mangledName Make `IRGlobalValue::mangledName` a `Name*` 22 February 2018, 20:35:11 UTC
ac1dfba Yong He 22 February 2018, 20:08:47 UTC Make `IRGlobalValue::mangledName` a `Name*` This allows us to get rid of `IRGlobalValue::dispose()`. 22 February 2018, 20:09:50 UTC
7eaaf1a Tim Foley 22 February 2018, 19:44:57 UTC Initial work on validating "constexpr"-ness in IR (#420) * Initial work on validating "constexpr"-ness in IR The underlying issue here is that certain operations in the target shading languages constrain their operands to be compile-time constants. A notable example is the optional texel offset parameter to the `Texture2D.Sample` operation. When calling these operations in GLSL, the user is required to pass a "constant expression," and any variables in that expression must therefore be marked with the `const` qualifier (and themselves be initialized with constant expressions). Any GLSL output we generate must of course respect these rules. When calling these operations in HLSL, the user is not so constrained. Instead, they can pass an arbitrary expression, which may involve ordinary variables with no particular markup, and then the compiler is responsible for determining if the actual value after simplification works out to be a constant. In some cases, the requirement that a value be constant might actually trigger things like loop unrolling. Also, it is okay to use a function parameter to determine such a constant expression, as long as the argument turns out to be a constant at all call sites. The way we have decided to tackle these challenges in Slang is that we we propagate a notion of `constexpr`-ness through the IR. This is currently being tackled in `ir-constexpr.cpp` with a combination of forward and backward iterative dataflow: * When the operands to an instruction are all `constexpr`, and the opcode is one we believe can be constant-folded, then we infer that the instruction *can* be evaluated as `constexpr` * When instruction is required to be `constexpr`, then we infer that all of its operands are also required to be `constexpr`. If this process ever infers that a function parameter is required to be `constexpr`, then we might have to continue propagation at all the call sites to that function. If after all the propagation is done, there are any cases where an instruction is *required* to be `constexpr`, but it *can't* be `constexpr` (we weren't able to infer `constexpr`-ness for its operands), then we issue an error. This implementation encodes the idea of `constexpr`-ness in the IR as part of the type system, using a simplified notion of rates. This change adds a `RateQualifiedType` that can represent `@R T`, and then introduces a `ConstExprRate` that can be used for `R`. Many accessors for the type information on IR nodes were updated to distinguish when one wants the "full" type of an IR value (which might include rate information) vs. just the "data" type. A `constexpr` qualifier was added in the front-end, and is being used to decorate the texel offset parameter for `Texture2D.Sample`. Lowering from AST to IR looks for this qalifier and infers when a function parameter must be typed as `@ConstExpr T` instead of just `T`. There are lots of limitations and gotchas in the implementation so far: * The `@ConstExpr` rate is the only one added in this change, but it seems clear that the conceptual `ThreadGroup` rate that was added to represent `groupshared` should probably get folded into the representation. * I'm not 100% pleased with how many places in the IR I have to special-case for rate-qualified types. At the same type, pulling out rate as a distinct field on `IRValue` would probably require that we pay attention to rate everywhere. * I've added a test case to show that we can issue errors when users fail to provide a constant expression for the texel offset, but the actual error message isn't great because it doesn't indicate *why* a constant expression was required. Realistically the "initial IR" should contain a few more decorations we can use to relate error conditions back to the original code (even if this is in a side-band structure). * I've added a test case that is supposed to show that we can back-propagate `constexpr`-ness to local variables, and I've manually confirmed that it works for Vulkan/SPIR-V output, but the level of Vulkan support in `render_test` today means I can't enable the test for check-in. * While I'm attempting to propagate `@ConstExpr` information from callees to callers, I haven't implemented any logic to specialize callee functions based on values at call sites. * In a similar vein, there is no handling of control-flow dependence in the current code. If we infer that a phi (block parameter) needs to be `@ConstExpr`, then it isn't actually enough to require that the inputs to the phi (arguments from predecessor blocks) are all `@ConstExpr` because we also need any control-flow decisions that pick which incoming edge we take to be `@ConstExpr` as well. * As a practical matter, implicit propagation of `@ConstExpr` from a function body to a function parameter should only be allowed for functions that are "local" to a module. Any function that might be accessed from outside of a module should really have had its `@ConstExpr` parameter marked manually, and our pass should validate that they follow their own rules. Right now we have no kind of visibility (`public` vs `private`) system, so I'm kind of ignoring this issue. While that is a lot of gaps, this is also just enough code to get the Falcor MultiPassPostProcess example working, so I'm inclined to get it checked in. * Fixup: missing expected output for test * Fixup: disable test that relies on [unroll] for now 22 February 2018, 19:44:57 UTC
01c4134 Yong He 21 February 2018, 04:55:51 UTC Merge pull request #417 from csyonghe/leakfix Fix IR memory leaks. 21 February 2018, 04:55:51 UTC
4cf46e5 Yong He 20 February 2018, 23:50:41 UTC bug fix: witnessTable's subTypeDeclRef should have default substitution for getSpecailizedMangledName to work properly. 20 February 2018, 23:50:41 UTC
61a6d18 Yong He 20 February 2018, 21:34:59 UTC make CompileRequest retain specailized IR module. This is to workaround with the issue that the Types returned in ProgramLayout may reference to IRWitnessTables via GlobalGenericParamSubstitution. 20 February 2018, 21:34:59 UTC
5de62bb Yong He 20 February 2018, 00:53:45 UTC more to fixing memory leaks 1. reorder destruction order of several key classes to avoid using deleted IR objects when destroying Types 2. remove Session::canonicalTypes and make each Type own a RefPtr to the canonicalType, to allow types to be destroyed along with each IRModule it belongs to. 20 February 2018, 00:53:45 UTC
ff8adf7 Yong He 19 February 2018, 18:00:51 UTC Fix IR memory leaks. 1, make IRModule class own a memory pool for all IR object allocations 2. For now, we allow IR objects to own other (externally) heap allocated objects, such as String, List and RefPtrs by tracking all IR objects that has been allocated for the IRModule in a list named `IRModule::irObjectsToFree`. and call destructor for all these objects upon the destruction of the IRModule. In the long term, we should eliminate the use of all these externally allocated types in IR system and get rid of this tracking and explicit destructor calls. 3. remove non-generic `createValueImpl` functions and retain only generic versions in IRBulider so we can properly call the constructor of the IR types to set up virtual tables correctly for destructor dispatching. 4. add `MemoryPool` class for allocation of the IR objects. 5. Make sure we are disposing IRSpecContexts when we are done with the specialized IR module. 6. Add `_CrtDumpMemoryLeaks()` calls to check memory leaks upon destruction of a Slang session. If we are to support multiple sessions at a time, this call should probably be replaced with the more advanced MemoryState versions of the memory leak checker. 19 February 2018, 20:26:26 UTC
51cdcad Tim Foley 18 February 2018, 16:08:46 UTC stdlib fixes for Vulkan (#414) * stdlib fixes for Vulkan - Make sure to emit `image*` instead of `texture*` for `RWTexture*` types - Change `GetDimensions` to call `imageSize` instead of `textureSize` when we use images - Always output a `layout(rgba32f)` for variables that translate to `image` types - TODO: we should emit an appropriate format based on the type, or let the user specify one - Fix GLSL translation for `any()` function (required boolean inputs) - Add GLSL translation for `GroupMemoryBarrierWithGroupSync()` - Map HLSL `groupshared` to GLSL `shared` These together are enough to get the Falor `ComputeShader` example to work. * fixup for warning 18 February 2018, 16:08:46 UTC
8c87259 Tim Foley 16 February 2018, 20:00:20 UTC Implement IR-level translation of system values for GLSL (#413) The approach here isn't ideal. We already have a pass that transforms HLSL varying input/output types into GLSL global variables. This change makes it so that when those inputs/outputs have system-value semantics, we generate a global variable declaration with the appropriate `gl_*` name (leaving the type the same for now). Later, when emitting code, we just skip emitting declarations for declarations with mangled names that start with `gl_*`. A more complete implementation will be needed later on, which handles cases where the translation requires types to be changed (so that conversion code needs to be inserted). 16 February 2018, 20:00:20 UTC
1b93da0 Tim Foley 16 February 2018, 17:04:44 UTC IR/Vulkan fixes (#412) * Fix bugs around IR legalization of GLSL input/output - Add case to handle assignment of one `ScalarizedVal::Flavor::address` to another (still need to make sure we are handling all the possible cases there) - Revamp logic for creating global variable declarations for varying inputs/outputs. - Actually handle creating array declarations (not sure if binding locations will be correct) - Properly deal with offsetting of locations for nested fields - Only create varying input/output layout information as needed for the separate `in` and `out` variables we create to represent a single HLSL `inout` varying * During SSA generation, recursively remove trivial phis This is actually written up in the original paper I used as a reference, but I hadn't implemented the case yet. When you eliminate one phi as trivial (because its only operands were itself and at most one other value), you might find that another phi becomes trivial (because it had this phi as an operand, but now it will have the other value...). The one thing that made any of this tricky is that our "phi" nodes are really block parameters, and thus they don't technically have operands (`IRUse`s). The `IRUse`s for each phi were being tracked in a separate array, and had their `user` field set to null. With this change, I set their `user` to be the corresponding `IRParam` for the phi (and that means I changed `IRParam` to inherit from `IRUser` even though it shouldn't really be required). * Re-build SSA form after specialization/legalization The main reason to do this is that legalization might scalarize types, and thus might allow us to clean up resource-type local variables that we were not able to clean up when they were part of an aggregate. Note: we shouldn't really need to do this, because the front-end should actually be guaranteeing that types that include resources are used in "safe" ways, but we currently don't have the analyses required to support that. * Give an error message if we get GLSL input The API and command-line interface still recognize and nominally support GLSL input files, because they need to be supported in the "pass-through" mode. This change just adds an error message if we encounter a GLSL input file in anything other than "pass-through" mode. 16 February 2018, 17:04:44 UTC
3254970 Tim Foley 13 February 2018, 18:22:54 UTC Fix a bug in IR use-def information (#406) The basic problem here is that when unlinking an `IRUse` from the linked list of uses, there were several cases where I was failing to set the `prevLink` field of the next node to match the `prevLink` field of the node being removed. That doesn't show up when walking the linked list of uses forward, but it breaks it whenever you have subsequent unlinking operations. This change fixes the bugs of that kind I could find, and also adds a debug validation method to try to avoid breaking it again. I also made more access to `IRUse` go through accessor methods rather than using fields directly, to try to avoid this kind of error. I stopped short of making anything `private`, because I tend to find that it creates more hassles than it avoids. A few other fixes along the way: - Made the `List<T>` type default-initialize elements when you resize it. I hadn't realized we weren't doing that. - Add a standalone `dumpIR(IRGlobalValue*)` so help when debugging issues. 13 February 2018, 18:22:54 UTC
214a1fc Tim Foley 10 February 2018, 05:27:26 UTC Handling of duplicate global shader parameter declarations (#405) * Issue error when shader parameter type doesn't match between translation units We currently allow users to compile different translation units at the same time for the vertex and fragment shader, and those different translation units might contain distinct declarations for the "same" parameter. Furthermore, those declarations might use distinct declaratins of the "same" type. We currently bind those as if they were one parameter, which means we assume they have types that are actually equivalent. Unfortunately, things break when that isn't the case. This change adds error messages when parameter declarations that are determined to be the "same" don't have types that are either equiavlent or match "structurally" (same names, same fields, and field types match recursively). Ideally most users won't see these errors, because they will only submit single files to the compiler. Eventually we may actually decide to require that case and simplify our logic. * Support types with layout coming from a "matching" type Because of how the front-end performs parameter binding, we can end up in cases where a variable is given a `TypeLayout` based on a "matching" type from another translation unit (because the "same" shader parmaeter got declared in multiple TUs). This change tries to support that use case by avoiding absolute field decl-refs in the representation used for type legalization, so that we don't end up in a situation where we look up field layout based on information that doesn't match. 10 February 2018, 05:27:26 UTC
c7c97ad Tim Foley 08 February 2018, 22:46:12 UTC Basic IR support for `static const` globals (#404) * Basic IR support for `static const` globals Our strategy for lowering global *variables* can fall back to putting their initialization into a function, but that isn't really appropriate for global constants (it also isn't appropriate for arrays, but we'll need to deal with that seaprately). This change adds a distinct case for global constants (rather than treating them as variables), and forces the emission logic to always emit them as a single expression. Doing this makes assumptions about how the IR for these constants gets emitted (and what optimziations might do to it). In order to make things work, I had to switch the handling of initializer-list expressions to not be lowered via temporaries and mutation (since that isn't a good fit for reverting to a single expression). I've added a single test case to ensure that this works in the simplest scenario. My next priority will be to see if this unblocks my work in Falcor. * Fixup: bug fixes 08 February 2018, 22:46:12 UTC
112caca Tim Foley 08 February 2018, 15:54:04 UTC Falcor fixes (#402) * Re-define deprecated compile flags By including these flags in the header file, with a value of zero, we can allow some existing code to compile even after the major changes to the implementation. * The `SLANG_COMPILE_FLAG_NO_CHECKING` option will effectively be ignored, since checking is always enabled. * The `SLANG_COMPILE_FLAG_SPLIT_MIXED_TYPES` option will now act as if it is always enabled (and indeed some of the code has been relying on this flag being set always). * Make subscript operators writable for writable textures This even had a `TODO` comment saying that we needed to fix it, and now I'm seeing semantic checking failures because we didn't define these and so we find assignment to non l-values. * Fix definitions of any() and all() intrinsics These should always return a scalar `bool` value, but they were being defined wrong in two ways: 1. They were using their generic type parameter `T` in the return type 2. They were returning a vector in the vector case, and a matrix in the matrix case. This change just alters the return type to be `bool` in all cases. * Fix bug in SSA construction When eliminating a trivial phi node, it is possible that the phi is still recorded as the "latest" value for a local variable in its block. When later code queries that value from the block (which can happen whenever another block looks up a variable in its predecessors), it would get the old phi and not the replacement value. I simply added a loop that checks if the value we look up is a phi that got replaced, and then continues with the replacement value (which might itself be a phi...). A more advanced solution might try to get clever and have the map itself hold `IRUse` values so that we can replace them seamlessly. * Simplify IR control flow representation This change gets rid of various special-case operations for conditional and unconditional branches, and instead requires emit logic to recognize when a direct branch is targetting a `break` or `continue` label. The new approach here isn't perfect, but it seems beter than what we had before, because it can actually work in the presence of control-flow optimizations (including our current critical-edge-splitting step). * Load from groupshared isn't groupshared When loading from a `groupshared` variable, the resulting temporary shouldn't have the `groupshared` qualifier on it. This might eventually need to generalize to a better understanding of storage modifiers in the IR, but I don't really want to deal with that right now. * Don't emit references to typedefs in output code Now that we are using the IR for all codegen, we shouldn't be dealing with surface-level things like `typedef` declarations in the output code; just use the type that was being referred to in the first place. * Fix floating-point literal printing for IR The IR was calling `emit()` instead of `Emit()` (we really need to normalize our convention here), and was implicitly invoking a default constructor on `String` that takes a `double` (that constructor should really be marked `explicit`), and which doesn't meet our requirements for printing floating-point values. * Fix error when importing module that doesn't parse We already added a case to bail out if semantic checking fails, but neglected to add a case if there is an error during parsing of a module to be imported. Note: this logic doesn't correctly register the module as being loaded (but still in error), so users could see multiple error messages if there are multiple `import`s for the same module. * Improve error message for overload resolution failure - Drop debugging info from the candidate printing - Add cases to print `double` and `half` types properly * Fixup: switch loopTest to ifElse in expected IR output 08 February 2018, 15:54:04 UTC
be8b891 Tim Foley 07 February 2018, 22:37:37 UTC Generate SSA form for IR functions (#400) * Generate SSA form for IR functions The basic idea here is simple: in the front-end after we have lowered the AST to initial IR we will apply a set of "mandatory" optimization passes. The first of these is to attempt to translate the all functions into SSA form so that they are amenable to subsequent dataflow optimizations. Eventually, the mandatory optimization passes would include diagnostic passes that make sure variables aren't used when undefined, etc. Just doing basic SSA generation already cleans up a lot of the messiness in our IR today, because constructs that used to involve many local variables can now be handled via SSA temporaries. The implementation of SSA generation is in `ir-ssa.cpp`, and it follows the approach of Braun et al.'s "Simple and Efficient Construction of Static Single Assignment Form." I used this instead of the more well-known Cytron et al. algorithm because Braun's algorith mis very simple to code, and does not require auxiliary analyses to generate the dominance frontier. The main wrinkle in our SSA representation right now is that instead of using ordinary phi nodes, we instead allow basic blocks to have parameters, where predecessor blocks pass in different parameter values. This encodes information equivalent to traditional phi nodes, but has two (small) benefits: 1. There is no fixed relationship between the order of phi operands and predecessor blocks, so we don't have to worry about breaking the phis when we alter the order in which predecessors are stored. This is important for us because predecessors are being stored implicitly. 2. It is easy to operationalize a "branch with arguments" either when lowering to other languages, or when interpreting the IR. A branch with arguments is implemented as a sequence of stores from the arguments to the parameters of the target block (very similar to a call), followed by a jump to the block. Relevant to the above, this change also adds an interface for enumerating the predecessors or successors of a block in our CFG. Rather than use an auxliary structure, we directly use the information already encoded in the IR: * The sucessors of a block are the target label operands of its terminator instruction. In our IR this is a contiguous range of `IRUse`s, possible with a stride (to account for the way `switch` interleaves values and blocks). * The predecessors of a block are a subset of the uses of the block's value. Specifically, they are any uses that are on a terminator instruction, and within the range of values that represent the successor list of that instruction. One important limitation of the "blocks with arguments" model for handling phis is that it is really only convenient to stash extra arguments on an unconditional terminator instruction. This change works around this prob lem by breaking any "critical edges" - edges between a block with multiple successors and one with multiple predecessors. We assume that "phi" nodes will only ever be needed on a block with multiple predecessors, and because critical edges are broken, each of these predecessors will then have only a single successor, so its branch instruction can handle the extra arguments. This change introduces a notion of an "undefined" instruction in the IR. This is handled as an instruction rather than a value because I anticipate that we will want to distinguish different undefined values when it comes time to start issuing error messages (those messages will need to point to the variable that was used when undefined). * Fix expected test output. Another change was merged that enabled the `glsl-parameter-blocks` test, and its output is affected by our IR optimization work. 07 February 2018, 22:37:37 UTC
1fbc73d Tim Foley 07 February 2018, 21:41:43 UTC Support __target_intrinsic modifiers in IR codegen (#401) The standard library already has a bunch of these decorations, since they were added to support Slang->Vulkan codegen on the AST-to-AST path. This change makes the IR code generator able to exploit the modifiers so that we pick up a bunch of Vulkan support "for free" in the short term. The basic change is in `lower-to-ir.cpp` where we copy over any `TargetIntrinsicModifier`s to become `IRTargetIntrinsicDecoration`s with the same information. We then need a bit of logic in `ir.cpp` to make sure we clone them as needed. The core work of using the modifiers is in `emit.cpp`, where I basically just copy-pasted the existing logic that applied in the AST path (all the AST-related code there is dead, and we should clean it up soon). The big change that comes with this logic is that when dealing with a member function, the numbering of the argument used in the intrinsic definition string changes, so that `$0` refers to the base object (whereas before the base object was looked up via the base expression of a `MemberExpr` used for the function). This requires a bunch of the definitions in the library to be updated; hopefully I caught them all. For kicks, I've re-enabled a cross-compilation test just to confirm that we are generating valid SPIR-V for code that performs texture-fetch operations. I don't expect us to keep that test enabled as-is in the long term, though, because it would be much better to instead use render-test to do the same thing. Alas, beefing up the Vulkan support in render-test is an outstanding work item, and I didn't want to pollute this change with more work along those lines. 07 February 2018, 21:41:43 UTC
662f43f Tim Foley 03 February 2018, 15:30:54 UTC Remove non-IR codegen paths (#398) The basic change is simple: remove support for all code generation paths other than the IR. There is a lot of vestigial code left, but the main logic in `ast-legalize.*` is gone. Doing this breaks a *lot* of tests, for various reasons: - We can no longer guarantee exactly matching DXBC or SPIR-V output after things pass through out IR - Many builtins don't have matching versions defined for GLSL output via IR (even when they had versions defined via the earlier approach that worked with the AST) - A lot of code creates intermediate values of opaque types in the IR, which turn into opaque-type temporaries that aren't allowed (this breaks many GLSL tests, but also some HLSL) I implemented some small fixes for issues that I could get working in the time I had, but most of the above are larger than made sense to fix in this commit. For now I'm disabling the tests that cause problems, but we will need to make a concerted effort to get things working on this new substrate if we are going to make good on our goals. 03 February 2018, 15:30:54 UTC
58475a8 Tim Foley 02 February 2018, 18:38:22 UTC Revamp documentation (#395) - Remove references to building by embedding source (not recommended at this point) - Push users more toward binary builds rather than building from source (but include a document that talks about how to build) - Remove most (all?) references to supporting GLSL input - Expand the language guide to talk about the new features - Add a document that talks about the parameter layout algorithm 02 February 2018, 18:38:22 UTC
0360f81 Tim Foley 02 February 2018, 16:49:04 UTC Remove support for the -no-checking flag (#392) * Remove support for the -no-checking flag Fixes #381 Fixes #383 Work on #382 - No longer expose flag through API (`SLANG_COMPILE_FLAG_NO_CHECKING`) and command-line (`-no-checking`) options - Remove all logic in `check.cpp` that was withholding diagnostics (including errors) when the no-checking mode was enabled - Remove `HiddenImplicitCastExpr`, which was only created to support no-checking mode (it represented an implicit cast that our checking through was needed, but couldn't emit because it might be wrong) - Remove logic for storing function bodies as raw token lists when checking is turned off. I'm leaving in the `UnparsedStmt` AST node in case we ever need/want to lazily parse and check function bodies down the line. - Remove a few of the code-generation paths we had to contend with, but keep the comment about them in place. - Remove GLSL-based tests that can't meaningfully work with the new approach. - Fix other tests that used a GLSL baseline so that their GLSL compiles with `-pass-through glslang` instead of invoking `slang` with the `-no-checking` flag. - Remove tests that were explicitly added to test the "rewriter + IR" path, since that is no longer supported. There is more cleanup that can be done here, now that we know that AST-based rewrite and IR will never co-exist, but it is probably easier to deal with that as part of removing the AST-based rewrite path. We've lost some test coverage here, but actually not too much if we consider that we are dropping GLSL input anyway. * Fixup: test runner was mis-counting ignored tests * Fixup: turn on dumping on test failure under Travis * Fixup: enable extensions in Linux build of glslang 02 February 2018, 16:49:04 UTC
b034398 Tim Foley 02 February 2018, 15:49:32 UTC Initial work on getting render-test to support vulkan (#391) * Basic fixes to gets some Vulkan GLSL out of the IR path We haven't been paying much attention to the Vulkan output from the IR path, but that needs to change ASAP. This commit really just implements quick fixes, without concern for whether they are a good fit in the long term. - Add some more mappings from D3D `SV_*` semantics to built-in GLSL variables, and stop redeclaring those built-in variables in our output GLSL. - Add custom output logic for HLSL `*StructuredBuffer<T>` types, so that they emit as `buffer` declarations with an unsized array inside. This has some real limitations: - What if the user passes the type into a function? The parameter should be typed as an (unsized) array, and not a buffer. - What happens if we have an array of structured buffers? We need to declare an array of blocks (which GLSL allows), but this changes the GLSL we should emit when indexing. - Customize the way that we emit entry point attributes (e.g., `[numthread(...)]`) to also support outputting equivalent GLSL `layout` qualifiers. In many of these cases, a better fix might involve doing more of this work in the IR as part of legalization (e.g., we already have a pass that deals with varying input/output for GLSL, so that should probalby be responsible for swapping the `SV_*` to `gl_*`, especially in cases where the types don't match perfectly across langauges). * Start adding Vulkan support to render-test - Add both Vulkan and D3D12 as nominally supported back-ends - Add a git submodule to pull in the Vulkan SDK dependencies - I don't want our users to have to install it manually, since the SDK is huge - Checking in the binaries to our main repository seems like a bad idea, but my hope is that we can prune the bloat using a subodule with the `shallow` cloning option - Implement enough logic for the Vulkan back-end to get a single test passing on Vulkan * Fix warning * Fixup: disable new compute tests for Linux * Fixup: ignore Vulkan tests on AppVeyor * Dynamically load Vulkan implementation Rather than statically link to the Vulkan library, we will dynamically load all of the required functions. This removes the need to have the stub libs involved at all. * Remove vulkan submodule I had set up a `vulkan` submodule to pull in the headers and stub libs, but now that we are going to dynamically load all the symbols anyway, the stub lib binaries aren't needed and we can just commit the headers. * Add Vulkan headers to external/ 02 February 2018, 15:49:32 UTC
652a3c9 Tim Foley 01 February 2018, 22:41:34 UTC Fix a bug in import handling (#394) The recent change that removed `#import` accidentally introduced a regression that made *any* code that imports the same module in more than one place fail. I'm just fixing the bug for now to unblock users, but this should really get a regression test. 01 February 2018, 22:41:34 UTC
4583e39 Tim Foley 01 February 2018, 20:06:06 UTC Implement type splitting for raw buffers (#393) * Fix render-test to handle raw buffers I don't know if this fix will work for UAVs that are neither structured nor raw, but it fixes the code that currently only really works if every UAV is structured (since it doesn't set a format). * Make type legalization consider raw buffer types The type layout logic was already handling these, but the type splitting logic in legalization was failing to split structure types that contain, e.g., `RWByteAddressBuffer`. A compute test case has been added to confirm the fix. 01 February 2018, 20:06:06 UTC
b6bc083 Tim Foley 30 January 2018, 00:32:52 UTC Remove #import directive (#389) Fixes #380 The `#import` directive was a stopgap measure to allow a macro-heavy shader library to incrementally adopt `import`, but it has turned out to cause as many problems as it fixes (not least because users have never been able to form a good mental model around which kind of import to do when). This change yanks support for the feature. 30 January 2018, 00:32:52 UTC
06f0eff Tim Foley 26 January 2018, 23:30:23 UTC Fix handling of errors in imported modules (#387) * Fix handling of errors in imported modules - If a semantic error is detected in an imported module, then don't try to generate IR code for it - Also, if a module (transitively) imports itself, then report that as an error - The way I'm checking for this is a bit hacky (I'm adding the module to the map of loaded modules, but in an "unfinished" state, and then using that unfinished state to detect the import of a module already being imported). This isn't a 100% complete solution for any of the related problems, but it improves the user experience for the common case. * Remove #import test. The feature is slated to be removed, so it isn't worth fixing up this test case. 26 January 2018, 23:30:23 UTC
a050f4a Tim Foley 26 January 2018, 21:23:16 UTC Fix some crashing bugs around local variable declarations. (#385) The basic problem here arises when a local variable is used either before its own declaration: ```hlsl int a = b; ... int b = 0; ``` or when a local variable is used *in* its own decalration: ```hlsl int b = b; ``` In each case, Slang considers the scope of the `{}`-enclosed function body (or nested statement) as a whole, and so the lookup can "see" the declaration even if it is later in the same function. This behavior isn't really correct for HLSL semantics, so the right long-term fix is to change our scoping rules, but for now users really just want the compiler to not crash on code like this, and give an error message that points at the issue. This change makes both of the above examples print an error message saying that variable `b` was used before its declaration, which is accurate to the way that Slang is interpreting those code examples. This is currently treated as a fatal error, so that compilation aborts right away, to avoid all of the downstream crashes that these cases were causing. 26 January 2018, 21:23:16 UTC
4cd18ec Yong He 23 January 2018, 21:04:45 UTC Update README.md 23 January 2018, 21:04:45 UTC
94fd60e Yong He 22 January 2018, 02:25:05 UTC Merge pull request #379 from tfoleyNV/generic-extension-fixes Generic extension fixes 22 January 2018, 02:25:05 UTC
f114c37 Tim Foley 22 January 2018, 02:03:35 UTC A hacky fix for specializing methods from extensions If we don't find the generic we expect in the first pass during IR specialization, then we check for the special case where we are trying to specialize something from a generic extension, using the type being extended. We assume that the generic parameter lists match (that part is the huge hack), and collect the arguments as if they were for the extension instead of the type. This will break when/if we ever have generic extensions with parameter lists that don't match the type being extended. 22 January 2018, 02:06:40 UTC
ef2f92f Tim Foley 22 January 2018, 01:23:03 UTC Trying to get generic extensions to work - Don't drop specializations on a method when adding it to requirement dictionary - Handle extension declarations under a generic when emitting to IR 22 January 2018, 02:06:40 UTC
4131120 Tim Foley 22 January 2018, 02:05:39 UTC Fix legalization of generic types (#377) Previously, all legalizations of a generic type would use the name of the original decl for the "ordinary" part of things, and this would lead to collisions because the names didn't include the mangled generic arguments. This is now fixed by storing the mangled name of the original inside of `struct` declarations created for legalization, and using those names instead. Also adds support for `getElementPtr` instructions when doing IR type legalization. Also tries to make a `DeclRefType` convert to a string using the underlying `DeclRef`. This doesn't help because `DeclRef::toString` doesn't actually include generic arguments either. 22 January 2018, 02:05:39 UTC
8196dc4 Yong He 22 January 2018, 00:26:52 UTC specialize witness tables when needed when specializing `lookup_witness_table` instruction. (#376) 22 January 2018, 00:26:52 UTC
4044a1d Yong He 21 January 2018, 18:48:31 UTC Merge pull request #372 from csyonghe/master Allow type expression as type argument, fix global param enum order 21 January 2018, 18:48:31 UTC
f681a15 Tim Foley 21 January 2018, 17:45:58 UTC Add directive to ignore file for test runner 21 January 2018, 17:45:58 UTC
ce87911 Yong He 21 January 2018, 12:09:55 UTC Improvements and bug fixes for global type parameters 1. allow spReflection_FindTypeByName to accept arbitrary type expression string 2. allow const int generic value to be used as expression value, and as array size 3. various bug fixes in witness table specialization / function cloning during specializeIRForEntryPoint to avoid creating duplicate global values, not copying the right definition of a function from the other module, not cloning witness tables that are required by specializeGenerics etc. 21 January 2018, 12:09:55 UTC
913f4d0 Yong He 20 January 2018, 07:48:12 UTC bug fixes fixes #373 fixes bug that misses current translation unit's scope when resolving entry-point global type argument expression. 20 January 2018, 07:48:12 UTC
6dd64fd Yong He 20 January 2018, 03:20:29 UTC Make specialization presserve global parameter enumeration order in reflection data 20 January 2018, 03:21:29 UTC
9d515dd Yong He 19 January 2018, 23:20:23 UTC Allow arbitrary type string as type argument in spAddEntryPointEx. 20 January 2018, 03:21:29 UTC
2079b94 Yong He 18 January 2018, 20:49:59 UTC Merge pull request #371 from csyonghe/master All compiler fixes to get ir branch work with falcor feature demo. 18 January 2018, 20:49:59 UTC
9eb8b4e Yong He 18 January 2018, 20:51:32 UTC rename expected test result file. 18 January 2018, 20:51:32 UTC
9cecdfb Yong He 18 January 2018, 01:58:00 UTC cleanup unused code. 18 January 2018, 01:58:00 UTC
caf6f7a Yong He 17 January 2018, 19:48:07 UTC All compiler fixes to get ir branch work with falcor feature demo. - support overloaded generic function. this involves adding a new expression type, `OverloadedExpr2` to hold the candidate expressions for the generic function decl being referenced. - make BitNot a normal IROp instead of an IRPseudoOp - make sure we clone the decorations of parameters when cloning ir functions - propagate geometry shader entry point attributes (`[maxvertexcount]` and `[instance]`) through HLSL emit - IR emit: handle geometry shader entry-point parameter decorations, such as 'triangle'. - IR emit: treat geometry shader stream output typed ir value as `should fold into use`. 18 January 2018, 01:54:56 UTC
68f529a Yong He 16 January 2018, 22:52:06 UTC Merge pull request #370 from csyonghe/master bug fixes to get falcor example shader code to compile. 16 January 2018, 22:52:06 UTC
a74a549 Yong He 16 January 2018, 20:38:36 UTC bug fixes to get falcor example shader code to compile. 1. prevent cyclic lookups when an interface inherits transitively from itself. 2. in `createGlobalGenericParamSubstitution`, create a default substitution for the base type declref before using it to lookup the witness table. 16 January 2018, 20:38:36 UTC
59691ae Yong He 16 January 2018, 18:52:10 UTC Allow extension on interface (#369) This completes item 5 in issue #361. The interesting change is that when checking for interface conformance, we include the requirements (include transitive interfaces) defined in extensions as well. (check.cpp line 1946) All the other changes are for one thing: reoder the semantic checkings to two explicit stages: check header and check body. In check header phase, we check everything except function bodies, register all extensions with their target decls, then check interface conformances for all concrete types. In body checking phase, we look inside the function bodies and check concrete statements/expressions. This change ensures that we take extension into consideration in all places where it should be. 16 January 2018, 18:52:10 UTC
68fd448 Yong He 16 January 2018, 03:22:39 UTC Merge pull request #367 from csyonghe/extension2 Support transitive interfaces 16 January 2018, 03:22:39 UTC
513f56b Yong He 15 January 2018, 23:30:11 UTC cleanup debug code 15 January 2018, 23:30:11 UTC
3d4eaf3 Yong He 15 January 2018, 23:15:49 UTC Support transitive interfaces This commit is a bunch of quick hacks to get transitive interfaces to work. The idea is for each concrete type we create one giant witness table that contains entries for all the transitively reachable interface requirements, and then create one copy of that witness table for each interface it implements. `DoLocalLookupImpl` now also looks up in inherited interface decles when looking up for a symbol in an interface decl. When visiting `InheritanceDecl` in `lower-to-ir`, create copies of the giant witness table for each transitively inherited interface, so that these witness tables can be found later when the IR is specialized. Re-enable the `copy all witness tables` hack in `specializeIRForEntryPoint` to ensure those transitive witness tables are copied over. 15 January 2018, 23:18:25 UTC
8abae05 Yong He 15 January 2018, 21:54:57 UTC Merge pull request #365 from csyonghe/extension Allow extension of a concrete type to implement additional interface 15 January 2018, 21:54:57 UTC
cff418b Yong He 15 January 2018, 21:54:32 UTC Merge branch 'master' into extension 15 January 2018, 21:54:32 UTC
e86ab5f Yong He 15 January 2018, 21:21:34 UTC Merge pull request #366 from csyonghe/keywordrename add support for `extension` and `type_param` keywords 15 January 2018, 21:21:34 UTC
8e67c48 Yong He 15 January 2018, 02:38:35 UTC add support for `extension` and `type_param` keywords 15 January 2018, 02:38:35 UTC
436f0e7 Yong He 14 January 2018, 23:20:46 UTC temporary workaround to fix test case failures. 14 January 2018, 23:20:46 UTC
ae8ef43 Yong He 14 January 2018, 21:52:02 UTC Fixup field lookup from a member function defined in an extension This fixes item 2 in #361 Modifies existing extension-multi-interface.slang test case to cover the additional scenario. 14 January 2018, 21:52:02 UTC
d33e6b7 Yong He 14 January 2018, 21:22:11 UTC allow extension of a concrete type to implement additional interface Also support the scenario that the extension declares conformance to interface I, and a method M in I is already supported by the base implementation. 14 January 2018, 21:22:11 UTC
d4dab2c Yong He 13 January 2018, 21:17:02 UTC Merge pull request #364 from csyonghe/assoctype Support nested generics 13 January 2018, 21:17:02 UTC
4d2086f Yong He 13 January 2018, 20:17:43 UTC Fix creation of `ThisTypeSubstitution`. `createDefaultSubstitutions` now responsible for creating a `ThisTypeSubstitution` when `decl` is an `InterfaceDecl`. This is to ensure a reference to an associated type decl from the same interface that defines the assoctype decl will get a `ThisTypeSubstitution` so that the right hand side of it can be replaced by future substitutions. 13 January 2018, 20:17:43 UTC
99f49e4 Yong He 13 January 2018, 19:30:37 UTC remove out-of-date changes 13 January 2018, 19:30:37 UTC
4b284da Yong He 09 January 2018, 21:26:42 UTC Support nested generics fixes #362 13 January 2018, 04:55:38 UTC
df6eeb9 Yong He 12 January 2018, 22:15:56 UTC Refactor substitution representation in DeclRefBase (#363) This commit changes the type of `DeclRefBase::substitutions` from `RefPtr<Substitutions>` to `SubstitutionSet`, which is a new type defined as following: ``` struct SubstitutionSet { RefPtr<GenericSubstitution> genericSubstitutions; RefPtr<ThisTypeSubstitution> thisTypeSubstitution; RefPtr<GlobalGenericParamSubstitution> globalGenParamSubstitutions; } ``` This change get rid of most helper functions to retreive the substitution of a certain type, as well as surgery operations to insert a `ThisTypeSubstitution` or `GlobalGenericTypeSubstittuion` at top or bottom of the substitution chain. It also simplies type comparison when certain type of substitution should not be considered as part of type definition. 12 January 2018, 22:15:56 UTC
8daafcc Yong He 09 January 2018, 18:50:44 UTC bruteforce implementation of witness table resolution for associated (#358) 09 January 2018, 18:50:44 UTC
3d435f7 Yong He 04 January 2018, 21:41:09 UTC Bug fixes for Slang integration (#356) * fix #353 * move validateEntryPoint to after all entrypoints has been checked * bug fix: DeclRefType::SubstituteImpl should change ioDiff * bug fix: generic resource usage should have count of 1 instead of 0. * update test case 04 January 2018, 21:41:09 UTC
e90dfcf Yong He 04 January 2018, 02:09:35 UTC Merge pull request #349 from csyonghe/master Add API for querying TypeLayout from a Type 04 January 2018, 02:09:35 UTC
550405d Yong He 04 January 2018, 01:15:03 UTC Fix type lookup of global type arguments Global type argument lookup should be done in both loaded modules and current trnaslation units. This is the same as the logic of spReflection_FindTypeByName, so it is extracted into `CompileRequest::lookupGlobalDecl(Name*)` method and reused in places. 04 January 2018, 01:15:03 UTC
61b206d Yong He 04 January 2018, 01:12:46 UTC Merge https://github.com/shader-slang/slang 04 January 2018, 01:12:46 UTC
5da16a6 Tim Foley 04 January 2018, 00:22:37 UTC Fix bug around arrays of structs of resources (#352) Should fix #351 The basic problem is that the type layout logic in Slang isn't taking into account the way that resource-type fields in aggregate types get split. When you just have a bare aggregate, this oversight doesn't cause a problem, but once you put those aggregates into an array, the problems become clear. Given: ```hlsl struct Test { Texture2D a; Texture2D b; }; Test test[8]; ``` The default type-layout algorithm gives `Test::a` an offset of zero, and `Test::b` an offset of one. However, after splitting, we have something like: ```hlsl Texture2D test_a[8]; Texture2D test_b[8]; ``` It is clear in this case that `test_b` can't start at an offset of one relative to `test_a` - it needs to start at `register(t8)`. This change handles things by adjusting the layout of an array type to account for this detail as soon as it is created. The alternative would have been to not change layout rules at all, but to instead try to adjust things at the point where types get split (and the layout for the un-split case gets applied to the split variable). The reason for doing it the way it is in this change is that the reflection API will hopefully provide accurate information. Related to reflection information, one thing that is missing here is proper computation of the "stride" for an array like this. We'll see if that needs to be addressed in a follow-up. 04 January 2018, 00:22:37 UTC
771da26 Yong He 03 January 2018, 20:53:16 UTC spReflection_FindTypeByName: add lookup in translationUnits. 03 January 2018, 20:53:16 UTC
36bc65a Yong He 03 January 2018, 20:47:46 UTC Merge https://github.com/shader-slang/slang 03 January 2018, 20:47:46 UTC
9f89c3b Yong He 03 January 2018, 20:46:23 UTC Add API for querying TypeLayout from a Type Added two API functions: 1. `spReflection_FindTypeByName`, which returns a DeclRefType to the struct type with the given name. The function finds from all loaded modules in a `CompileRequest` for a decl with the given name, construct a `Type` object and cache it in `CompileRequest::types` dictionary. The subsequent calls to `spReflection_FindTypeByName` with the same name will simply returned the cached Type objects. 2. `spReflection_GetTypeLayout`, which returns a `TypeLayout` for a given `Type`. This function creates and caches the `TypeLayout` in the `TargetRequest` object that is used to create the `ProgramLayout`. 03 January 2018, 20:46:23 UTC
f52b93e Yong He 03 January 2018, 20:38:48 UTC add call to `EnsureDecl` in `SpecializeGenericForOverload`. 03 January 2018, 20:38:48 UTC
51f0701 Tim Foley 03 January 2018, 18:17:17 UTC Fix struct decl order again (#348) * Add core.natvis file to Slang DLL build It seems that when `slang.dll` gets loaded into a user's project, the debugger is able to pick up the custom visualizers implemented in `slang.natvis` (which is directly added to the DLL project) but not `core.natvis` (which is added to a static library project that the DLL project references). Adding `core.natvis` to the DLL project directly seems to resolve this and greatly improve the debugging experience when in user code. * Bug fix: emit type of CB before CB when using IR The problem here was the logic for emitting types used by an IR declaration before the declaration. I refactored it to share logic between variables with initializers and functions, but in doing so failed to have an ordinary variable (which includes constant buffers) ensure that its own type was emitted before the variable. This is a one-line fix. 03 January 2018, 18:17:17 UTC
1e0aabf Yong He 03 January 2018, 06:04:50 UTC no-codegen compile flag and global generics reflection (#347) * no-codegen compile flag and global generics reflection 1. Add SLANG_COMPILE_FLAG_NO_CODEGEN (-no-codegen) compiler flag to skip code generation stage, so that a shader that uses global generic type parmameters can be parsed, checked and introspected without knowing the final specialization. 2. Add reflection API to query for global generic type parameters, global parameters of generic type, and the generic type parameter index related to a global generic parameter. 3. Add a reflection test case for global generic type parameters. * add expected result for global-type-params test case. * fix reflection json output. * fix branch condition errors * fix expected result for global-type-params.slang * fix expected test case output 03 January 2018, 06:04:50 UTC
66f9a7c Tim Foley 02 January 2018, 18:44:05 UTC Bug fix for humane source location computation. (#346) Fixes #345 A brief refresher: a `SourceLoc` in the Slang implementation is just an integer (more or less an absolute byte index into all of the source compiled so far). We convert that integer to a "humane" source location (a file name and line/column numbers) by finding the file and line that match the integer via binary search. The data structures used for that search are owned by a `SourceManager`. In order to avoid running out of source locations when used in a long-running application (that might reload shaders many times), the implementation creates one `SourceManager` per `CompileRequest`, along with a single shared `SourceManager` that is used for locations in the builtin libraries. The root of the bug here was that some code was using the `SourceManager` for a compile request when it should have been using the one for the builtins. This happened because one source manager was asked to translate a `SourceLoc` into a humane location, which first involves "expanding" that location (figuring out which file it belongs to, and which source manager owns that file), and failed to realize that the expanded location might use a different source manager (either the current one or one of its "parents"). I fixed this by reworking the API so that the mapping from an expanded location to a humane one is no longer a member of a source manager (since the correct source manager can be looked up in the associated expanded location). Hopefully this will prevent this class of error in the future. 02 January 2018, 18:44:05 UTC
17369d9 Tim Foley 02 January 2018, 17:29:21 UTC Always respect dependency order when lowering decls via AST (#344) Fixes #333 The code in `ast-legalize` is passed an array of declarations that have been ordered by dependencies using a topological sort. Unfortunately, it was only using that list in the case where the request was considered to be a "rewrite" request, and would otherwise rely on the order in which things get forced during the recursive walk (which doesn't really work for our needs). 02 January 2018, 17:29:21 UTC
bdc1fa5 Yong He 29 December 2017, 04:32:02 UTC Merge pull request #342 from csyonghe/fix-341 Fix type substitution for associatedtype 29 December 2017, 04:32:02 UTC
37cff92 Yong He 29 December 2017, 03:51:58 UTC fixup substitution of typedef associated type implementation via GetType() call. 29 December 2017, 03:51:58 UTC
ee1ea35 Yong He 28 December 2017, 22:43:45 UTC Merge branch 'struct-in-generic' 28 December 2017, 22:43:45 UTC
9efd959 Yong He 28 December 2017, 22:38:05 UTC Fix substitution for associatedtype. fixes #341 When a typedef definition is used to satisfy an associated type, we must also substitute the resulting typedef type using parent substitution, in the case that the typedef is a generic application. 28 December 2017, 22:39:14 UTC
bcfe836 Yong He 28 December 2017, 12:18:27 UTC Merge pull request #340 from csyonghe/struct-in-generic Fix NameExprType returning deleted canonical type when it's in a generic parent 28 December 2017, 12:18:27 UTC
d46aeb0 Yong He 28 December 2017, 11:53:19 UTC Fix NameExprType returning deleted canonical type when it's in a generic parent. fixes #339 `NamedExpressionType::CreateCanonicalType()` may return a deleted pointer. The original implementation is as follows: ``` Type* NamedExpressionType::CreateCanonicalType() { return GetType(declRef)->GetCanonicalType(); } ``` If `GetType()` returns a newly constructed Type (this happens when the `typedef` is defined inside a generic parent, which triggers a non-trivial substitution), the temporary type will be deleted when the function returns. The fix is to store the temporary type as a field of NamedExpressionType (`innerType`). A relevant fix (though not the true cause of issue #339) is to have `Type::GetCanonicalType()` also hold a `RefPtr` to the constructed canonical type, when the canonical type is not `this`. This prevents a returned canonical type being assigned to a RefPtr, which makes it possible for that RefPtr to be the sole owner of the canonical type and deleteing the canonical type when that RefPtr is destroyed. 28 December 2017, 11:53:19 UTC
7e340c2 Yong He 28 December 2017, 07:13:37 UTC Merge pull request #337 from csyonghe/master Using a visitor to replace lookup scopes of generic function's return type expr 28 December 2017, 07:13:37 UTC
57d9498 Yong He 28 December 2017, 02:52:39 UTC Merge branch 'master' into master 28 December 2017, 02:52:39 UTC
eaf3d84 Yong He 28 December 2017, 02:51:56 UTC Using a visitor to systematically replace lookup scopes of generic function's return type expression. fixes #336 Add a `ReplaceScopeVisitor` to replace the scopes of the return type expression tree to use the generic decl's scope instead of module's scope after parser has determined the decl is a generic function header decl. 28 December 2017, 02:51:56 UTC
e370fe2 Yong He 28 December 2017, 01:17:36 UTC Merge pull request #335 from csyonghe/master Support nested generic types (e.g. L<T<S>>) 28 December 2017, 01:17:36 UTC
d55b56b Yong He 28 December 2017, 00:19:09 UTC fix test cases 28 December 2017, 00:19:09 UTC
3379f7a Yong He 28 December 2017, 00:02:22 UTC fix project file. 28 December 2017, 00:02:22 UTC
87cba14 Yong He 27 December 2017, 23:47:40 UTC Support nested generic types (e.g. L<T<S>>) fixes #325 This commit includes following changes: 1. Including a default DeclaredSubtypeWitness argument when creating a default GenericSubstitution for a DeclRefType, so that the witness argument can be successfully replaced with an actual witness table after specialization. (check,cpp) 2. Not emitting full mangled name for struct field members. Since the declref of the member access instruction do not include necessary generic substitutions for its parent generic parameters, so the mangled names of the declaration site and use site mismatches. Instead we just emit the original name for struct fields. (emit.cpp) 3. Allow IRWitnessTable to represent a generic witness table for generic structs. Adds necessary fields to IRWitnessTable for generic specialization. For now, the user field of the IRUse is not used and is nullptr. (ir-inst.h) 4. Make IRProxyVal use an IRUse instead of an IRValue*, so that an IRValue referenced by IRProxyVal (as a substitution argument) can be managed by the def-use chain for easy replacement. This is used for specializing witness tables. (ir.cpp, ir.h) 5. Add a `String dumpIRFunc(IRFunc*)` function for debugging. 6. Add name mangling for generic / specialized witness tables (mangle.cpp) 7. improved natvis file for inspecting witness tables. 8. Add specialization of witness tables: 1) `findWitnessTable` will simply return the specialize IRInst for a generic witness table. 2) make `cloneSubstitutionArg` call `cloneValue` to clone the argument instead of calling `context->maybeCloneValue`, so we can make use of the cloned value lookup machanism to directly return the specialized witness table (which is done when we process the `specialize` instruction on the generic witness table before process the decl ref). 3) bug fix: the argument in ir.cpp:3338 should be `newArg` instead of `arg`. 4) add `specializeWitnessTable` function to specailize a generic witness table. It clones the witness table, and recursively calls `getSpecailizedFunc` for the witness table entries. 5) make `specailizeGenerics` function also handle the case when an operand of the `specialize` instruction is a witness table. We will call `specializeWitnessTable` here and replace the `specialize` instruction with the specialized witness table. The replacement mechanism based on IR def-use chain works here because we have already make IRProxyVal a part of the def-use chain. 9. Add two more test cases for nested generics with constraints. (generic-list.slang and generic-struct-with-constraint.slang) 27 December 2017, 23:50:32 UTC
6924239 Yong He 27 December 2017, 02:04:53 UTC Merge pull request #330 from tfoleyNV/implicit-generic-app Support generic type constraints when implicitly invoking generic 27 December 2017, 02:04:53 UTC
fd0b8ca Yong He 27 December 2017, 01:20:54 UTC fix ast-lowering of `TransitiveSubtypeWitness` values. 27 December 2017, 01:20:54 UTC
4b53fd5 Tim Foley 22 December 2017, 20:09:39 UTC Merge branch 'master' into implicit-generic-app 22 December 2017, 20:09:39 UTC
d1c3852 Tim Foley 22 December 2017, 20:09:26 UTC Support for transitive subtype witnesses (#331) * Change stdlib `saturate` to explicitly specialize `clamp` This exposes issue #329, and so gives us an easy way to see if transitive subtype witnesses have been implemented correctly. * Fixup: invoke correct `clamp` overloads When switching the `clamp` calls in the stdlib definition of `saturate` I made two big mistakes: 1. I was passing in `<T>` in all cases, instead of, e.g., `<vector<T,N>>` in the vector case 2. Of course, the overloads don't actually take `<vector<T,N>>` for the vector case, because `vector<T,N>` is not a `__BuiltinArithmeticType` (`T` is), so instead it should be `clamp<T,N>(...)`. The issue behind (2) is that we don't support "conditional conformances," which would be a way to say that when `T : __BuiltinArithmeticType` then `vector<T,N> : __BuiltinArithmeticType`. That would be a great long-term wish-list feature, but not something I can see us adding in a hurry. Anyway the fix here is the simple one: change the vector/matrix call sites to invoke the correct overload in each case. * Add a notion of transitive subtype witnesses There are two pieces here: 1. Add the `TransitiveSubtypeWitness` class. This is a witness that `A : C` that works by storing nested subtype witnesses that show that `A : B` and `B : C` for some intermediate type `B`. All the basic `Val` operations are easy enough to define on this. - The one gotcha case is whether we can ever simplify away a `TransitiveSubtypeWitness` as part of substitution. That is, if we end up substituting so that both `A` and `B` end up as the same type, then we really just need the `B : C` sub-part. Stuff like that is left as future work. 2. Make the logic in `check.cpp` that constructs subtype witnesses based on found inheritance and constraint declarations able to build up transitive chains. Most of the required infrastructure was already there (the search process maintains a trail of "breadcrumbs" that represent all the steps getting from `A : B` to `B : C` to `C : D` ...). This change does *not* deal with the required changes in the IR to take advantage of transitive witnesses. 22 December 2017, 20:09:26 UTC
7ebc987 Tim Foley 22 December 2017, 18:48:55 UTC Support generic type constraints when implicitly invoking generic Fixes #326 This basically just copy-pastes logic from the explicit case over to the implicit case. After we've solved for the explicit type/value arguments, we loop over the constraints and for each one we try to find a suitable subtype witness to use (after substituting in the arguments solved so far). This change includes a test case for the new functionality. 22 December 2017, 18:50:32 UTC
fab52a1 Yong He 22 December 2017, 00:50:22 UTC Merge pull request #324 from tfoleyNV/generic-struct-specialization Support generic `struct` types during IR-based emit 22 December 2017, 00:50:22 UTC
0049015 Tim Foley 22 December 2017, 00:16:23 UTC Support generic `struct` types during IR-based emit Fixes #318 Most of the required support was actually in place, so this is just a bunch of fixes: - Detect when we are in "full IR" mode, so that we can always emit `struct` declarations with their mangled named (which will produce different names for different specializations, since we emit decl-refs) - Carefully exclude builtin types from this for now. We'll need a more complete solution for mapping HLSL/Slang builtin types to their GLSL equivalents soon. - Skip emitting types referenced by generic IR functions, since they might not be usable. - Also fix things up so that we emit types used in the initializer for any global variables. - Fix bug in generic specialization where we specialize the same function more than once, with different type arguments. We were crashing on a `Dictionary::Add` call where the key already exists from a previous specialization attempt. - Fix name-mangling logic so that when outputting a possibly-specialized generic it looks for the outer-most `GenericSubstitution` rather than just the first one in the list. This is to handle the way that we insert other substitutions willy-nilly in places where they realistically don't belong. :( All of these changes together allow us to pass a slightly modified (more advanced) version of the test case posted to #318. 22 December 2017, 00:16:23 UTC
back to top