| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, the Slang IR used a single opcode
(`kIROp_Undefined`) to encode all cases of undefined values. The
particular motivation for this change was a need to distinguish those
undefined values that represent a load from an uninitialized memory
location versus other sorts of undefined values. If transforming a
variable into SSA form results in `undefined` values in cases where the
a `load` was executed without a prior `store`, that represents an error
on the programmer's part, and should be diagnosed. However, other cases
of undefined values can arise during program transformation and
optimization, and should not typically result in diagnostics being
emitted.
While it was not the original motivation for this change, it is also
worth noting that the LLVM project has transitioned from initially using
only a single `undef` instruction to having a more nuanced model, and
the same factors that motivated their shift also apply to the Slang IR.
Counter-intuitively, the semantics of undefined values actually need to
be carefully defined.
Concretely, this change splits the pre-existing `undefined` opcode into
two sub-cases:
- `kIROp_LoadFromUninitializedMemory`, to represent the case of loading
from a memory location (such as a local variable) that has not been
initialized.
- `kIROp_Poison`, corresponding to the LLVM `poison` value.
Our poison instruction is intended to have semantics comparable to
LLVM's equivalent. Conceptually, any operation that is invoked with a
poison value as input will (with a few exceptions) produce a poison
value as output. One can think of the behavior of `poison` as similar to
how not-a-number values propagate in floating-point computations: by
default they "infect" the result of any computation they are involved
in. This semantic choice helps to ensure that many optimizations end up
being correct in the presence of undefined values, even if they did not
specifically account for them.
The `kIROp_LoadFromUninitializedMemory` case is comparable to the
combination of `freeze` and `undef` in LLVM. An LLVM `undef` value has
semantics that allow *each* use of that value to be replaced with a
*different* arbitrary value; these semantics cause many optimizations to
only be correct in the absence of undefined values. An LLVM `freeze`
instruction can take an undefined value as input, and produces a single
value that is still arbitrary, but must be consistent across all uses.
The latter semantics are what we want, since a given `load` from an
uninitialized memory location will yield an arbitrary-but-fixed value.
Note that we intentionally do not have a direct analogue to LLVM's
`undef` instruction, because of the way that `undef` causes so many
complications when trying to write optimizations.
We also do not add a `kIROp_Freeze` instruction in this change, but that
is simply because we currently have no need for it.
Existing code that was creating `IRUndefined` values has been updated to
create either `IRPoison` or `IRLoadFromUninitializedMemory` values, as
appropriate to the use case. Code that was checking for the
`kIROp_Undefined` opcode has been updated to either check for both of
the new opcodes (in the case of `switch` statements), or to use
`as<IRUndefined>` to perform a dynamic cast to the common base type of
the two new instructions.
Note that this change does not alter the way that instructions
representing undefined values are typically emitted as ordinary
instructions in the block that produces an undefined value. While
emitting `IRLoadFromUninitializedMemory` as an ordinary instruction is
exactly what we want, the `IRPoison` case would actually be better
represented in Slang IR as a "hoistable" instruction, so that there
would only be a singular `poison` value of each type. Changing
`IRPoison` to be hoistable would be a good follow-up change, but might
run into more challenges depending on what assumptions (if any) the
codebase is making about where undefined values get emitted.
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that while this change touched a large numer of files, there are no
changes to functionality being made here. The only things being done are
renaming various symbols and, in a few cases, updating or adding
comments for consistency with the new names.
The core of the naming changes are:
* Most things named to refer to `OutType` (e.g., `IROutType`,
`IRBuilder::getOutType()`, etc.) have been consistently renamed to refer
to `OutParamType`, to emphasize that the relevant AST/IR node types are
only intended for use to represent `out` parameters.
* The same change as described above for `OutType` is also made for
`RefType`, which becomes `RefParamType` in most cases. One mess that
this exposes is the way that the `ExplicitRef<T>` type in the core
module currently lowers to `IRRefParamType`. This change sticks to the
rule of not making functional changes, so that mess is left as-is for
now.
* Names referring to `InOutType` have been changed to instead refer to
`BorrowInOutType`. The intention with this naming change is to emphasize
that the Slang rules for `inout` are semantically those of a borrow (or
at least our interpretation of what a borrow means).
* Names referring to `ConstRefType` have been changed to instead refer
to `BorrowInType`. This change starts work on clarifying that the
existing `__constref` modifier was never intended to be a read-only
analogue of `__ref`, and instead is the input-only analogue of `inout`.
* The `ParameterDirection` enum type has been changed to
`ParamPassingMode`, to reflect the fact that the concept of "direction"
fails to capture what is actually being encoded, particularly once we
have modes beyond simple `in`/`out`/`inout`.
While this change does not alter behavior in any case (the user-exposed
Slang language is unchanged), it is intended to set up subsequence
changes that will work to make the handling of these types in the
compiler more nuanced and correct. Breaking this part of the change out
separately is primarily motivated by a desire to minimize the effort for
reviewers.
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add fkYAML submodule
* Generate slang-ir-inst-defs.h from slang-ir-inst-defs.yaml
* generate ir-inst-defs.h
* neaten things
* neaten inst def parser
* add rapidyaml submodule
* remove fkyaml
* remove fkyaml submodule
* remove use of ir-inst-defs.h
* format and warnings
* fix wasm build
* tidy
* remove rapidyaml
* Extend fiddle to allow custom splices in more places
* Use lua to describe ir insts
* fix
* neaten
* neaten
* neaten
* spelling
* neaten
* comment comment out assert
* merge
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow LHS of `where` to be any type.
* Register free-form extensions when loading precompiled module.
* Fix test.
* Fix.
* Fix `as<IRType>`.
* try fix precompiled module test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix incorrect resolve of specialization instance
While checking the uninitialized variables, we were not resolving the
specialized instance correctly. This commit repeats the resolve while
the result is a specialization instance. A new test is added for this:
tests/diagnostics/uninitialized-generic.slang
After the problem is fixed, it revealed another problem in existing
tests:
tests/compute/nested-generics2.slang
tests/diagnostics/uninitialized-local-variables.slang
When a struct has a member variable whose type is a generic type,
we cannot iterate over its member variables yet, because the type
is unknown until the generic function/struct is specialized. We will
have to give up checking for these cases.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Move switch statement bodies to their own lines
* format
---------
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
| |
* format
* Minor test fixes
* enable checking cpp format in ci
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Cleanup atomic intrinsics.
* Fix.
* Fix glsl.
* Remove hacky intrinsic expansion logic for glsl image atomics.
* Fix all tests.
* Fix.
* Add `InterlockedAddF16Emulated`.
* Fix glsl intrinsic.
* Fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialization (#5023)
* Look through attributes and rates when determining by reference initialization
Closes #5022
* Make type of unwrapAttributedType more specific
* loosen type of unwrapAttributedType
* Discard changes to source/slang/slang-emit-spirv.cpp
* Discard changes to source/slang/slang-ir-check-differentiability.cpp
* Discard changes to source/slang/slang-ir.cpp
* Discard changes to source/slang/slang-ir.h
* Update slang-ir-use-uninitialized-values.cpp
* Remove redundant cast
---------
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Initial Atomic<T> type implementation.
* Update design doc.
* Fix.
* Add test.
* Fixes and add tests.
* Fix WGSL.
* Fix glsl.
* Fix metal.
* experiemnt with github metal.
* experiment github metal 2
* github metal experiment 3
* experiment with github metal 4.
* experiment with metal 5.
* experiment 7.
* metal experiment 8.
* Fix metal tests.
---------
Co-authored-by: Yong He <yhe@nvidia.com>
|
| |
|
|
|
|
|
|
|
| |
* Add `IRWArray` interface, and make StructuredBuffer conform to them.
* Update user guide.
* Fix.
* Fixes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Ignoring construct field warnings on delegatory methods
* Generalizing instruction usage type interface
* Skip collection when searching for stores
* Adding separate construct delegation tests
* Treating differentiable functions as stores
|
| |
|
|
|
|
|
|
|
|
| |
hang (#4885)
* Track uninitialized values of `Ptr<Specialize<T>>` inside type `T` without hang
Fixes #4878
Track uninitialized values of `Ptr<Specialize<T>>` inside type `T` without hang
* change method used to resolve base of specialization
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the warnings were:
```
environment.slang(22): warning 41022: inout parameter 'seed' is never written to
public float3 environment_sample(StructuredBuffer <Environment_sample_data> sample_buffer, inout int seed)
^~~~~~~~~~~~~~~~~~
hit.slang(5): warning 41022: inout parameter 'seed' is never written to
float3 sample_lights(inout uint seed)
^~~~~~~~~~~~~
```
With this commit they should not be emitted.
|
| |
|
|
|
|
|
| |
Addresses #4698 as one approach to diagnose the potential problem.
Emit warnings when a user marks a parameter as `inout` but never writes to it in the function. A new intrinsic function `unmodified(out T)` has been added to explicitly indicate that an `inout` variable will not be modified in the function.
This is only one way to address the specific validation error in #4698. In general it seems that DXC does some more extensive checks on actual struct fields (as opposed to observing arbitrary struct writes), so that will be the next step.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Proper warning generation for target switches and intrinsic asm
* Relaxing terminators
* Fix compiler warnings
* Rectified target switch reachability check
* Simplify target switch reachability check
* Refactoring variable names
* Using getBlocks
* Moving ad hoc special case to diagnostics source
* Using the LINE directive for testing
* Simplifying reliance on target switches
* Skipping IR generation for empty target switches
---------
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Disable warnings for input global variables
* Update comment to reflect actual check
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
* Update comments in uninitialized-globals.slang
* Update uninitialized-globals.slang
* Refactoring test variable
* Typo in test
---------
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Detect uninitialized fields in constructors
* Reachability check for early returns
* Specialized warnings for synthesized default initializers
* Handling quirks with constructors
* Addressing review comments
* Ignore synthesized constructors if they are not used
|
| |
|
| |
Previously the warning system ignores undefined variables in nested scopes (blocks in IR).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Handle out/inout functions with separate consideration
* Fixing bug with passing aliasable instructions
* Handle autodiff functions (fwd and rev) in warning system
* Handling interface methods
* Handling ref parameters like out/inout
* Temporary fix to remaining bugs
* Refactoring methods and tests
* Recursive check for empty structs
* Using default initializable interface in tests
* Resolving CI fail
|
|
|
This extends the code for handling uninitialized output parameters.
Still needs to handle generic templates and assignment of uninitialized
values more carefully.
The file containing the relevant code are now in
source/slang/slang-ir-use-uninitialized-values.cpp
rather than the previous
source/slang/slang-ir-use-uninitialized-out-param.h
and the top-level function is now checkForUsingUinitializedValues.
Additionally a rudimentary test shader has been added for this case, which replaces the old file for out params only; tests/diagnositcs/uninitialized-out.slang becomes tests/diagnositcs/uninitialized.slang.
What this does not implement (could be future PRs):
* Checking uninitialized fields within constructors
* Partially uninitialized values with respect to data structure (e.g. arrays/structs/vector types)
* Partially uninitialized values with respect to control flow (e.g. if/else/loop)
|