[RFC][NVPTX] Update data layout string to include null pointer value spec - #195178
[RFC][NVPTX] Update data layout string to include null pointer value spec#195178shiltian wants to merge 1 commit into
Conversation
PR #183207 introduced support in the data layout for targets to specify the actual nullptr value per address space. If not specified, it defaults to zero. This PR updates the NVPTX data layout string accordingly.
|
This stack of pull requests is managed by sgh. |
|
Since I don't really work on NVPTX backend, I don't know if this PR is correct. Please let me know. |
| // RUN: %clang_cc1 -triple nvptx-unknown -o - -emit-llvm %s | \ | ||
| // RUN: FileCheck %s -check-prefix=NVPTX | ||
| // NVPTX: target datalayout = "e-p:32:32-p6:32:32-p7:32:32-i64:64-i128:128-i256:256-v16:16-v32:32-n16:32:64" | ||
| // NVPTX: target datalayout = "e-p:32:32-po3:32:32-po5:32:32-p6:32:32-po7:32:32-i64:64-i128:128-i256:256-v16:16-v32:32-n16:32:64" |
There was a problem hiding this comment.
General question -- how did we arrive at the conclusion that these AS should use all-ones nullptr?
I do not think I've seen it documented publicly for NVIDIA GPUs.
There was a problem hiding this comment.
That's my educated guess 🙂
- AMDGPU uses all-ones for
nullptrin AS 3 and 5, and we happen to use those address spaces with similar semantics. - For AS 7, it looks like in LLVM IR the
nullptrisn't represented asptr addrspace(7) null, but rather asaddrspacecast ptr null to addrspace(7), which suggests it isn't a zero value. Since we don't expect any other pattern right now, all-ones seems like the most reasonable assumption.
There was a problem hiding this comment.
@gonzalobg @AlexMaclean Any thoughts on what kind of nullptr makes sense for particular AS on NVIDIA GPUs?
|
I'm going to close this PR at this moment, since the infrastructure is not ready so to update them right now will cause some inconsistency, but please do let me know what ASs have non-zero null pointer value such that I can update them locally to test my changes. FYI, #183215 this PR stack shows where we are heading. |
PR #183207 introduced support in the data layout for targets to specify the
actual nullptr value per address space. If not specified, it defaults to zero.
This PR updates the NVPTX data layout string accordingly.