Following the discussion on D118229, this marks all pointer-typed kernel arguments as having ABI alignment, hopefully addressing the regression from that change.
Details
Diff Detail
Event Timeline
LGTM. I will defer to Anastasia.
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2478 | Pls add a reference to the OpenCL spec in the comment: OpenCL spec v3.0.10 Appendix C Alignment of Application Data Types: |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | Why does opencl need special treatment here? Isn't this the default behavior for all abi/languages? |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | In C++, references are required to be aligned (see the case directly above this), but pointers generally aren't. |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | No, at least not in generic code. We used to assume this, but it has been fixed a few releases back. |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | I agree it doesn't seem to be kernel-specific, should this apply to all functions? However, I wonder why this should need a special case in OpenCL C compared to C behavior? I feel the spec reference is not entirely related as all it's trying to say is that the host code is responsible to make sure the data are aligned in accordance with the device. Looking at LangRef it doesn't state what the default values for alignments are: |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | Ok I think this might be a more relevant reference:
However it still feels like it says that we expect data passed from host are adequately aligned? So I feel like this might be an implementation specific aspect that spec doesn't actually regulate... |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | The conformance test does check the low bits of the pointer are aligned |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | I don't think in general we can assume pointers are naturally aligned. There are valid use cases of pointers to non-aligned types, e.g. a member of a packed structure. A function with a pointer-type argument should accept pointer arguments to non-aligned types. OpenCL pointer-type kernel arguments are special cases where the alignment is guaranteed by the spec. |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 |
What if such types are used in kernel arguments, I can't see any related restrictions...
Ok, just to understand a bit more... has the failure been introduced recently or is this a new test? |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | The test started failing recently due to no longer using the pointee element types' ABI alignment. clang needs to start providing it in the IR explicitly |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 |
Isn't this covered by the part of the OpenCL spec you quoted above? Pointers can generally be unaligned, but for pointer arguments to kernels the spec requires that they are aligned. |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | I am still confused why the fix is only needed for the kernel functions now... Has there been any change in LLVM IR that triggers this issue? Is there some specific handling happening in for the functions that are regular and therefore are being called in contrast to kernels that are normally not called on the kernel side? |
clang/lib/CodeGen/CGCall.cpp | ||
---|---|---|
2479 | To unconfuse (mainly myself) the difference here is that OpenCL spec actually fixes the alignment of types in contrast to C/C++ that only specifies the alignment requirements. However OpenCL spec does special case kernel function parameters which is why the normal functions still remain regulated by C/C++ rules... not sure it was intentional but the change is reasonable. |
clang/test/CodeGenOpenCL/kernel-param-alignment.cl | ||
---|---|---|
10–13 ↗ | (On Diff #405938) | Should throw in some vectors for good measure |
Pls add a reference to the OpenCL spec in the comment:
OpenCL spec v3.0.10 Appendix C Alignment of Application Data Types:
The user is responsible for ensuring that pointers passed into and out of OpenCL kernels are natively aligned relative to the data type of the parameter as defined in the kernel language and SPIR-V specifications.