|
80 | 80 | [sycl-2020-spec-constant-glossary]: https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#specialization-constant |
81 | 81 | [sycl-2020-glossary]: https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#glossary |
82 | 82 |
|
83 | | -And implementation is based on [SPIR-V speficiation][spirv-spec] support |
| 83 | +And implementation is based on [SPIR-V specification][spirv-spec] support |
84 | 84 | for [Specialization][spirv-specialization]. However, the specification also |
85 | 85 | states the following: |
86 | 86 |
|
@@ -172,7 +172,7 @@ Based on those limitations, the following mapping design is proposed: |
172 | 172 | ``` |
173 | 173 | namespace detail { |
174 | 174 | // assuming user defined the following specialization_id: |
175 | | - // constexpr specialiation_id<int> int_const; |
| 175 | + // constexpr specialization_id<int> int_const; |
176 | 176 | // class Wrapper { |
177 | 177 | // public: |
178 | 178 | // static constexpr specialization_id<float> float_const; |
@@ -341,7 +341,7 @@ used to identify the specialization constants at SPIR-V level. |
341 | 341 | As noted above one symbolic ID can have several numeric IDs assigned to it - |
342 | 342 | such 1:N mapping comes from the fact that at SPIR-V level, composite |
343 | 343 | specialization constants don't have dedicated IDs and they are being identified |
344 | | -and specialized through their scalar leafs and corresponding numeric IDs. |
| 344 | +and specialized through their scalar leaves and corresponding numeric IDs. |
345 | 345 |
|
346 | 346 | For example, the following code: |
347 | 347 | ``` |
@@ -375,7 +375,7 @@ unique_symbolic_id_for_id_A -> { 1, 2, 3 } |
375 | 375 |
|
376 | 376 | As it is shown in the example above, if a composite specialization constant |
377 | 377 | contains another composite within it, that nested composite is also being |
378 | | -"flattened" and its leafs are considered to be leafs of the parent |
| 378 | +"flattened" and its leaves are considered to be leaves of the parent |
379 | 379 | specialization constants. This done by depth-first search through the composite |
380 | 380 | elements. |
381 | 381 |
|
@@ -509,8 +509,8 @@ constant in that buffer: |
509 | 509 | ``` |
510 | 510 | [ |
511 | 511 | 0, // for id_int, the first constant is at the beginning of the buffer |
512 | | - 4, // sizeof(int) == 4, the second constant is located right after the fisrt one |
513 | | - 16, // sizeof(int) + sizezof(A) == 4, the same approach for the third constant |
| 512 | + 4, // sizeof(int) == 4, the second constant is located right after the first one |
| 513 | + 16, // sizeof(int) + sizeof(A) == 4, the same approach for the third constant |
514 | 514 | ] |
515 | 515 | ``` |
516 | 516 |
|
@@ -661,9 +661,9 @@ While transforming SYCL kernel function into an OpenCL kernel, DPC++ FE should |
661 | 661 | - Communicate to DPC++ RT which kernel argument should be used for passing |
662 | 662 | a buffer with specialization constant values when they are emulated. |
663 | 663 |
|
664 | | -DPC++ FE provides implementation of `__builtin_sycl_unique_id` built-in function and |
665 | | -it also populates special integration footer with the content required by DPC++ |
666 | | -RT for access to right device image properties describing specialization |
| 664 | +DPC++ FE provides implementation of `__builtin_sycl_unique_id` built-in function |
| 665 | +and it also populates special integration footer with the content required by |
| 666 | +DPC++ RT for access to right device image properties describing specialization |
667 | 667 | constants. |
668 | 668 |
|
669 | 669 | #### SYCL Kernel function transformations |
@@ -763,7 +763,7 @@ struct A { |
763 | 763 | }; |
764 | 764 |
|
765 | 765 | constexpr specialization_id<int> id_int; |
766 | | -struct Wraper { |
| 766 | +struct Wrapper { |
767 | 767 | public: |
768 | 768 | static constexpr specialization_id<A> id_A; |
769 | 769 | }; |
@@ -839,10 +839,10 @@ constexpr sycl::specialization_id<int> same_name{1}; |
839 | 839 |
|
840 | 840 | namespace { |
841 | 841 | constexpr sycl::specialization_id<int> same_name{2}: |
842 | | - /* application code that referenes ::(unnamed)::same_name */ |
| 842 | + /* application code that references ::(unnamed)::same_name */ |
843 | 843 | namespace { |
844 | 844 | constexpr sycl::specialization_id<int> same_name{3}: |
845 | | - /* application code that referenes ::(unnamed)::(unnamed)::same_name */ |
| 845 | + /* application code that references ::(unnamed)::(unnamed)::same_name */ |
846 | 846 | } |
847 | 847 | } |
848 | 848 |
|
@@ -899,7 +899,7 @@ namespace { |
899 | 899 |
|
900 | 900 | namespace __sycl_detail { |
901 | 901 | // Sometimes we need a 'shim', which points to another 'shim' in order to |
902 | | - // "extract" a variable from an anonymous namespace unambiguosly |
| 902 | + // "extract" a variable from an anonymous namespace unambiguously |
903 | 903 | static constexpr decltype(__sycl_detail::__shim_1()) &__shim_2() { |
904 | 904 | // still address of ::(unnamed)::(unnamed)::same_name; |
905 | 905 | return __sycl_detail::__shim_1(); |
@@ -972,7 +972,7 @@ address of the specialization constant provided by user and `offset` field of |
972 | 972 | the descriptor as `(char*)(SpecConstantValuesMap[SymbolicID]) + offset`. |
973 | 973 |
|
974 | 974 | That calculation is required, because at SPIR-V level composite |
975 | | -specialization constants are respresented by several specialization constants |
| 975 | +specialization constants are represented by several specialization constants |
976 | 976 | for each element of a composite, whilst on a SYCL level, the whole composite |
977 | 977 | is passed by user as a single blob of data. `offset` field from properties is |
978 | 978 | used to specify which exact piece of that blob should be extracted to perform |
@@ -1053,7 +1053,7 @@ the translator will generate `OpSpecConstant` SPIR-V instructions with proper |
1053 | 1053 | OpDecorate %A.float SpecId 44 ; ID of the 2nd member |
1054 | 1054 | %A.i32 = OpSpecConstant %int.type 0 ; 1st member with default value |
1055 | 1055 | %A.float = OpSpecConstant %float.type 0.0 ; 2nd member with default value |
1056 | | - %struct = OpSpecConstantComposite %struct.type %A.i32 %A.float ; Composite doens't need IDs or default value |
| 1056 | + %struct = OpSpecConstantComposite %struct.type %A.i32 %A.float ; Composite doesn't need IDs or default value |
1057 | 1057 | %1 = OpTypeFunction %int |
1058 | 1058 |
|
1059 | 1059 | %get = OpFunction %int None %1 |
|
0 commit comments