The folding rule `BitCastScalarOrVector` was incorrectly handling
bitcasting to unsigned integers smaller than 32-bits. It was simply
copying the entire 32-bit word containing the integer. This conflicts with the
requirement in section 2.2.1 of the SPIR-V spec which states that
unsigned numeric types with a bit width less than 32-bits must have the
high-order bits set to 0.
This change include a refactor of the bit extension code to be able to
test it better, and to use it in multiple files.
Fixes https://github.com/microsoft/DirectXShaderCompiler/issues/6319.
Those scripts are running on Python2.7 if build with the NDK tools.
Under python2.7, io.open will load as "utf-8" since we give the encoding
option, and return a "unicode" string.
Under Python3, the open() function will return a UTF-8 string.
This means the XMLParser needs to have a different 'encoding' option
depending on the python version.
For some reason I don't know, the XMLParser still fails if we use
'unicode' under Python2.7. But converting the unicode string to utf-8
does work.
Signed-off-by: Nathan Gauër <brioche@google.com>
With --nested-indent, the SPIR-V blocks are nested according to the
structured control flow. Each OpLabel is nested that much with the
contents of the block nested a little more. The blocks are separated by
a blank line for better visualization.
With --reorder-blocks, the SPIR-V blocks are reordered according to the
structured control flow. This is particularly useful with
--nested-indent.
Note that with --nested-indent, the disassembly does not exactly show
the binary as-is, and the instructions may be reordered.
This pass fixups the opcode used for OpExtInst instructions
to use OpExtInstWithForwardRefsKHR when it contains a forward
reference.
This pass is agnostic to the extension used, hence the validity
of the code depends of the validity of the usage:
If a forward reference is used on a non-semantic extended instruction,
the generated code will remain invalid, but the opcode will change.
What this pass guarantees is valid code won't become invalid.
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
Co-authored-by: Steven Perron <stevenperron@google.com>
PR #5648 added support for the GroupNonUniformPartitionedNV. But there
was an issue: the opcodes are enabled by multiple capabilities, and the
actual operand is what matters.
Added testing coverage and the implementation to correctly trim a few
NonUniform capabilities.
Signed-off-by: Nathan Gauër <brioche@google.com>
The KHR suffix was missing from the published SPIR-V extension.
This is now fixed, but requires some patches in SPIRV-Tools.
Signed-off-by: Nathan Gauër <brioche@google.com>
* val, core: add support for OpExtInstWithForwardRefs
This commit adds validation and support for
OpExtInstWithForwardRefs. This new instruction will be used
for non-semantic debug info, when forward references are
required.
For now, this commit only fixes the code to handle this new instruction,
and adds validation rules. But it does not add the pass to generate/fix
the OpExtInst instruction when forward references are in use.
Such pass would be useful for DXC or other tools, but I wanted to land
validation rules first.
This commit also bumps SPIRV-Headers to get this new opcode.
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
We replace getting the id of a poitner type with a specific funciton
call to FindPointerToType. Also, FindPointerToType is updated to not
indirectly call GetId. This leads to a linear search for an existing
type in all cases, but it is necessary.
Note that this function could have a similar problem. There could be two
pointer types with the same pointee and storage class, and the first one
will be returned. I have checked the ~20 uses, and they are all used in
situations where the id is used to create something new, and it does not
have to match an existing type. These will not cause problems.
Part of #5691
* Avoid use of type manager in extact->construct folding
When dealing with structs the type manager merge two different structs
into a single entry if they have all of the same decorations and
element types. This is because they hash to the same value in the hash
table. This can cause problems if you need to get the id of a type from
the type manager because you could get either one. In this case, it
returns the wrong one.
The fix avoids using the type manager in one place. I have not
looked closely at other places the type manager is used to make
sure it is used safely everywhere.
Fixes#5624
* Remove use of TypeManager::GetId
This removes a use of TypeManager::GetId by keeping the id around. This
avoid a potential problem if the type manager gets confused. These types
of bugs are hard to generate test cases for, so I do not have a test.
However, existing tests make sure that do not regress.
The last three elements in the list of supported targets were
misaligned:
```
Targets:
SPIR-V 1.0
SPIR-V 1.1
...
SPIR-V 1.3 (under Vulkan 1.1 semantics)
SPIR-V 1.4 (under Vulkan 1.1 semantics)
SPIR-V 1.5 (under Vulkan 1.2 semantics)
SPIR-V 1.6 (under Vulkan 1.3 semantics)
```
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
* Basic support for SPV_EXT_replicated_composites
Validation will follow as a separate PR (still need to write a test suite)
Change-Id: Ic95fa6ce39d32f5ac2787bc38dba2748c9cc58f7
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
* Update SPIRV-Headers
Change-Id: I6c0df248d99c13b49d78528d035a4222027c0232
---------
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
This removes the folding rules added in #4783 and #4808. They lead to
poor code generation on Adreno devices when 16-bit floating point values
were used. Since this change is transformation is suppose to be neutral,
there is no general reason to continue doing it.
I have talked to the owners of SwiftShader, and they do not mind if the
transform is removed. They were the ones the requested the change in the
first place.
Fixes#5658
The autoroller does not update abseil, and that it stopping us from
updating RE2. This change will update the auto roller, then the next
time it runs, we should be able to update everything.
The Scope operand of `OpReadClockKHR` was always validated using the
Vulkan environment rules, which only allow `Subgroup` or `Device`.
For the OpenCL environment, `Workgroup` is also a valid Scope, so
`Workgroup` should not be rejected in the universal environment.
Guard the existing Scope check behind `spvIsVulkanEnv` and add a new
Scope check for the OpenCL environment.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
* Check for matrix decorations on arrays of matrices
* MatrixStide, RowMajor and ColMajor can be applied to matrix or
arrays of matrix members
* Check that matrix stride satisfies alignment in arrays
Reject `OpCooperativeMatrixStoreKHR` with a `MakePointerVisibleKHR`
MemoryAccess operand, as `MakePointerVisibleKHR` is not supposed to be
used with store operations.
The `CoopMatKHRStoreMemoryAccessFail` test failed to catch this
because it used the helper function `GenCoopMatLoadStoreShader` which
generates `...NV` instead of `...KHR` instructions. Add a new helper
function to generate similar shaders for the KHR extension, as the NV
and KHR extensions have various subtle differences that makes
parameterizing the original helper function non-trivial.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
In contrast to the C API, the C++ API did not have symbol visibility
specified. An application using the C++ API would fail to link
against a shared SPIRV-Tools library built with `-fvisibility=hidden`.
Mark all classes in the public `.hpp` files with `SPIRV_TOOLS_EXPORT`.
Add `SPIRV_TOOLS_LOCAL` to hide nested structs containing
implementation details.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
* Disallow duplicate decorations generally
* Only FuncParamAttr and UserSemantic can be applied to the same target
multiple times
* Unchecked: completely duplicate UserSemantic and FuncParamAttr
* Disallow duplicate execution modes generally
* Exceptions for float controls, float controls2 and some intel
execution modes
* Fix invalid fuzzer transforms
This fixes the problem reported in #5623 using the observation that if
we are re-building a type that already exists in the type pool, we
should just return that type.
This makes type rebuilding more efficient, and it also prevents the
type builder from getting itself into infinite recursion (as reported in
this issue).
In fixing this, I found a couple of other bugs in the type builder:
- When rebuilding an Array type, we were not re-building the element
type. This caused stale type references in the rebuilt type.
- This bug had not been caught by the test, because the test itself had
a bug in it: the test was rebuilding types on top of the same ID (the
ID counter was never incremented).
Initially, the bug in the test caused a failure with the new logic in
the builder because we now return types from the pool directly, which
causes a failure when two incompatible types are registered under the
same ID.
Fixing that issue in the test exposed another bug in the rebuilder: we
were not re-building the element type for Array types. This was causing
a stale type reference inside Array types which was later caught by the
type removal logic in the test.
GitHub releases were just the exact same as the LunarG releases,
since the same commit were used for both.
For this reason, we don't think it brings any value, and will stop
publishing new releases on the GitHub page.
Signed-off-by: Nathan Gauër <brioche@google.com>
6598a8ecd5...917047f360
$ git log 6598a8ecd..917047f36 --date=short --no-merges --format='%ad %ae %s'
2024-03-28 junyer Tell Bazel the specific target version of macOS too. Sigh.
2024-03-28 junyer Force a specific target version of macOS.
2024-03-28 junyer Prepare to tag release `2024-04-01`.
Created with:
roll-dep external/re2
Co-authored-by: GitHub Actions[bot] <>
