You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creation of UniformConstant kind of variables may emit invalid SPIR-V code by reusing composite constants of array type with a wrong number of components. The key to understanding the issue is the following minimal reproducer that basically contains the biggest part of addressing the issue:
Here vectors of different length are set with @llvm.memset that is implemented via variables of UniformConstant kinds initialized by an array of the corresponding size. Wrong way of creating constants of array type makes it impossible for SPIRV Backend to distinguish between [1, 1, 1] and [1, 1, 1, 1, 1, ...] (repeated 16 times).
spirv-val catches that as
error: line 14146: Initializer type must match the type pointed to by the Result Type
%126 = OpVariable %_ptr_UniformConstant__arr_uchar_uint_16 UniformConstant %80
The text was updated successfully, but these errors were encountered:
…96514)
This PR fixes#96513.
The way of creation of array type constant was incorrect: instead of
creating [1, 1, 1] or [1, 1, 1, 1, 1, ....] constants, the same [1]
constant was always created, substituting original composite constants.
This in its turn led to a situation when only one of constants might
exist in the code without emitting invalid code, the second constant
would be eventually rewritten to the first constant, because a key to
address both was an array of a single element (like [1]).
This PR fixes the issue and purges from the code unneeded copy/pasted
clone of the function that creates an array constant.
…lvm#96514)
This PR fixesllvm#96513.
The way of creation of array type constant was incorrect: instead of
creating [1, 1, 1] or [1, 1, 1, 1, 1, ....] constants, the same [1]
constant was always created, substituting original composite constants.
This in its turn led to a situation when only one of constants might
exist in the code without emitting invalid code, the second constant
would be eventually rewritten to the first constant, because a key to
address both was an array of a single element (like [1]).
This PR fixes the issue and purges from the code unneeded copy/pasted
clone of the function that creates an array constant.
Creation of UniformConstant kind of variables may emit invalid SPIR-V code by reusing composite constants of array type with a wrong number of components. The key to understanding the issue is the following minimal reproducer that basically contains the biggest part of addressing the issue:
Here vectors of different length are set with @llvm.memset that is implemented via variables of UniformConstant kinds initialized by an array of the corresponding size. Wrong way of creating constants of array type makes it impossible for SPIRV Backend to distinguish between [1, 1, 1] and [1, 1, 1, 1, 1, ...] (repeated 16 times).
spirv-val catches that as
The text was updated successfully, but these errors were encountered: