This is an archive of the discontinued LLVM Phabricator instance.

[CUDA][HIP] Do not treat host var address as constant in device compilation
ClosedPublic

Authored by yaxunl on Jan 25 2022, 8:20 AM.

Details

Summary

Currently clang treats host var address as constant in device compilation,
which causes const vars initialized with host var address promoted to
device variables incorrectly and results in undefined symbols.

This patch fixes that.

Diff Detail

Event Timeline

yaxunl requested review of this revision.Jan 25 2022, 8:20 AM
yaxunl created this revision.
yaxunl updated this revision to Diff 402924.Jan 25 2022, 8:26 AM

fix test

tra added a comment.Jan 25 2022, 10:59 AM

LGTM.

Do we need to do anything special about __managed__ vars?

clang/lib/AST/ExprConstant.cpp
2224

Nit: Negations are my pet peeve. I think if (!(A||B||C||D...)) would be easier to read -- not (this or that or that) has only N+1 operations to keep in one's head vs 2*N in not this, and not that, and not that, and..... In this case it's not too bad, so I'll leave it up to you which form you prefer.

LGTM.

Do we need to do anything special about __managed__ vars?

Right __managed__ var is special. Its address is set by runtime, therefore it is not a constant. nvcc does not treat it as constant either. https://godbolt.org/z/jK534MxfG I will fix it.

BTW I just found a regression related to templates in CodeGenCUDA/host-used-device-var.cu. I will fix that and update this patch.

yaxunl updated this revision to Diff 403706.Jan 27 2022, 10:03 AM

Fix the regression in lit tests.

Basically in device compilation we still evaluate constant expression for host functions or host template instantiation. If we just disallow host variable in any constant expressions we will get errors in template class instantiation which use host variables as non-type template arguments.

Therefore we should only disallow host variables in constant expressions in situations when we are sure that allowing them will lead to issues, e.g. when promoting const variables.

A CUDAConstantEvaluationContext is introduced in ASTContext to control this.

tra added a subscriber: rsmith.Jan 27 2022, 12:09 PM

@rsmith -- is there anything else we need to worry about when it comes to treating pointers as constant values (or not)?

clang/lib/AST/ExprConstant.cpp
2227

Does it mean that we currently treat address of a __shared__ variable as a constant? Looks like we do: https://godbolt.org/z/eG4vG1rbf

__shared__ int s;
__device__ const int *const p2 = &s;

__device__ bool f() { return p2 == &s; }

f() currently always returns true, even though there will be multiple instances of s and we probably should not have allowed to init p2 to start with.

I think we should always return false for __shared__ vars.

clang/test/SemaCUDA/const-var.cu
2–3

Would it make sense to add a host-side test to illustrate a case where some pointer expressions will be const on the host side, but not on the device side?

18

I'd add a comment that global const variables are treated as __constant__. Otherwise no error on taking address of a on device side looks wrong.

Makes me wonder what would be result of B::p == B::p2? On device side, it should be possible to const evaluate it to true.
However, on the host, B::p would have a real value, but B::p2 will be represented by a proxy var. Off the top of my head I'm not sure whether it will be initialized or left undefined.

I'd add a codegen test to make sure B::p == B::p2 does get evaluated consistently on host and device.

yaxunl marked 4 inline comments as done.Jan 28 2022, 6:47 AM
yaxunl added inline comments.
clang/lib/AST/ExprConstant.cpp
2227

Will do. This is similar to a TLS var in C++, which is treated as non-constant by clang.

clang/test/SemaCUDA/const-var.cu
2–3

will do.

18

will do.

B::p == B::p2 evaluates to 1 on both device and host side.

yaxunl updated this revision to Diff 404010.Jan 28 2022, 6:48 AM
yaxunl marked 3 inline comments as done.

Revised by Artem's comments.

tra accepted this revision.Jan 28 2022, 12:00 PM
This revision is now accepted and ready to land.Jan 28 2022, 12:00 PM
This revision was landed with ongoing or failed builds.Jan 28 2022, 1:08 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 28 2022, 1:08 PM