num_simd_work_items and reqd_work_group_size argument checking

[AaronBallman]

The num_simd_work_items argument must evenly divide the reqd_work_group_size arguments. Does that mean this code should diagnose?

struct TRIFuncObjGood8 {
  [[intel::reqd_work_group_size(64, 64)]]
  [[intel::num_simd_work_items(4)]] void
  operator()() const {}
};

Note that reqd_work_group_size takes three arguments, two of which are optional and default to the value 1, which is not evenly divisible by 4.

According to https://www.intel.com/content/www/us/en/programmable/documentation/mwh1391807965224.html#mwh1391807939093 (section : 5.2.13. Specifying Number of SIMD Work-Items):

Important: Introduce the num_simd_work_items attribute in conjunction with the reqd_work_group_size attribute. The num_simd_work_items attribute you specify must evenly divide the work-group size you specify for the reqd_work_group_size attribute. 

I initially read this as having to evenly divide all of the work group size arguments (because a default value is still a value that is specified). But then I thought maybe the "you specify" means "you specify explicitly", so we'd only check the non-defaulted arguments. But then the example shown immediately below the text is:

__attribute__((num_simd_work_items(4)))
__attribute__((reqd_work_group_size(64,1,1)))

which explicitly specifies all three arguments! I started digging around to see if reqd_work_group_size has any documentation that suggests the first argument is the work group size (and the other arguments mean something different), but I didn't see any documentation on what those arguments mean individually (only collectively). So it's not clear what the diagnostic behavior should be.

[smanna12]

Tagging @GarveyJoe here incase he needs more information about the bug.

[MrSidims]

AFAIK this attribute is used as a hint for a device backend to specify work group sizes for ND range kernel. It's possible to have 3 dimensions (X, Y, Z) within ND range. I was under impression, that this requirement applies only for X argument of reqd_work_group_size attribute, but currently I can't prove this impression.

[AaronBallman]

That's what I'm starting to think the correct answer is, but the specification is very unclear about it. Once we validate what the intent is, hopefully we can open an issue to get the OpenCL docs clarified.

[GarveyJoe]

@MrSidims is right, it's only the X or 0th dimension that must be divisible by num_simd_work_items. I'll file a case to make this more clear in the docs.

[smanna12]

Thanks @AaronBallman, @MrSidims and @GarveyJoe for taking a look and comments about this bug. I will fix this bug in the compiler side.

[GarveyJoe]

My earlier comment is misleading because I used OpenCL-centric terminology. When I said the Xth or 0th dimension I was referring to the dimension that iterates the fastest. There's a gotcha here because the order of the arguments to reqd_work_group_size in SYCL and OpenCL are reversed. In the OpenCL syntax, reqd_work_group_size(X,Y,Z), X is the index that increments the fastest, followed by Y, then Z. If we preserve that definition of X, Y, and Z, then in SYCL the attribute is specified as reqd_work_group_size(Z,Y,X). This gets more complicated in the case where fewer than three arguments are provided. In such a case it's not the "X" argument that is omitted (by the definitions of X, Y, and Z above) it's the Z dimension that's omitted. So the two argument version has the syntax reqd_work_group_size(Y,X). Similarly, the one argument variant has syntax reqd_work_group_size(X). In summary, in SYCL the num_simd_work_items must evenly divide the last argument to reqd_work_group_size regardless of how many arguments req_work_group_size has.

[smanna12]

@GarveyJoe, Thanks for the comments.

In SYCL the attribute is specified as reqd_work_group_size(Z,Y,X).

This is not correct. in SYCL the attribute is specified as reqd_work_group_size(X,Y,Z). We do not swap the "X" and "Z" dimension values anymore in doing semantic checking, this only happens with codegen now after #2962 that i worked on.

So In summary, in SYCL the num_simd_work_items must evenly divide the first argument to reqd_work_group_size.

[smanna12]

My earlier comment is misleading because I used OpenCL-centric terminology. When I said the Xth or 0th dimension I was referring to the dimension that iterates the fastest. There's a gotcha here because the order of the arguments to reqd_work_group_size in SYCL and OpenCL are reversed. In the OpenCL syntax, reqd_work_group_size(X,Y,Z), X is the index that increments the fastest, followed by Y, then Z. If we preserve that definition of X, Y, and Z, then in SYCL the attribute is specified as reqd_work_group_size(Z,Y,X). This gets more complicated in the case where fewer than three arguments are provided. In such a case it's not the "X" argument that is omitted (by the definitions of X, Y, and Z above) it's the Z dimension that's omitted. So the two argument version has the syntax reqd_work_group_size(Y,X). Similarly, the one argument variant has syntax reqd_work_group_size(X). In summary, in SYCL the num_simd_work_items must evenly divide the last argument to reqd_work_group_size regardless of how many arguments req_work_group_size has.

I talked to @GarveyJoe offline. I misunderstood his comments on SYCL and OpenCL language design. This is clear now. Thanks.