|
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