[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -455,14 +456,22 @@ void createHostLayoutStructForBuffer(Sema &S, 
HLSLBufferDecl *BufDecl) {
   LS->setImplicit(true);
   LS->startDefinition();
 
-  for (const Decl *D : BufDecl->decls()) {
-const VarDecl *VD = dyn_cast(D);
+  for (Decl *D : BufDecl->decls()) {
+VarDecl *VD = dyn_cast(D);
 if (!VD || VD->getStorageClass() == SC_Static)
   continue;
 const Type *Ty = VD->getType()->getUnqualifiedDesugaredType();
 if (FieldDecl *FD = createFieldForHostLayoutStruct(
-S, Ty, VD->getIdentifier(), LS, BufDecl))
+S, Ty, VD->getIdentifier(), LS, BufDecl)) {
+  // add the field decl to the layout struct
   LS->addDecl(FD);
+  // update address space of the original decl to hlsl_constant
+  // and disable initialization
+  QualType NewTy =
+  AST.getAddrSpaceQualType(VD->getType(), LangAS::hlsl_constant);
+  VD->setType(NewTy);
+  VD->setInit(nullptr);

tex3d wrote:

Does this `VD->setInit(nullptr);` silently get rid of an initializer if there 
was one?  This feels a bit sketchy, unless I'm missing something.  I know we 
don't currently support capturing initializers for constant buffer values, but 
it is part of HLSL syntax and could in theory be captured.  Silently erasing it 
from the AST node at this point seems weird.

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

https://github.com/tex3d edited https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -83,6 +83,7 @@ const LangASMap AMDGPUTargetInfo::AMDGPUDefIsPrivMap = {
 llvm::AMDGPUAS::FLAT_ADDRESS, // ptr32_uptr
 llvm::AMDGPUAS::FLAT_ADDRESS, // ptr64
 llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_groupshared
+llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_constant

tex3d wrote:

Note: I noticed this uses `LangASMap`, but doesn't specify a value for 
`wasm_funcref`, which will invisibly initialize it to `0` (initializer shorter 
than array type `LangASMap`) and that maps to the dummy value of `FLAT_ADDRESS` 
likely desired anyway.  It doesn't rely on this auto-initialization for 
sycl_global and beyond though, even though it could.

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -2556,6 +2556,8 @@ std::string Qualifiers::getAddrSpaceAsString(LangAS AS) {
 return "__funcref";
   case LangAS::hlsl_groupshared:
 return "groupshared";
+  case LangAS::hlsl_constant:
+return "hlsl_constant";

tex3d wrote:

Should hlsl addrspace cases be ordered before `wasm_funcref`, like it is in the 
enum and everywhere else, just for consistency?

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -43,8 +43,8 @@ tbuffer B {
 // AST-NEXT: FullComment
 // AST-NEXT: ParagraphComment
 // AST-NEXT: TextComment {{.*}} Text=" CBuffer decl."
-// AST-NEXT: VarDecl {{.*}} a 'float'
-// AST-NEXT: VarDecl {{.*}} b 'int'
+// AST-NEXT: VarDecl {{.*}} a 'hlsl_constant float'
+// AST-NEXT: VarDecl {{.*}} b 'hlsl_constant int'

tex3d wrote:

Might we want a different address space for tbuffer, potentially?

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -42,6 +42,7 @@ static const unsigned DirectXAddrSpaceMap[] = {
 0, // ptr32_uptr
 0, // ptr64
 3, // hlsl_groupshared
+2, // hlsl_constant

tex3d wrote:

I'm surprised we neither use the `LangASMap` type for this array, nor 
static_assert that the size is the same, to prevent these from getting 
out-of-sync.  Does the assignment of this array pointer to `LangASMap *` cause 
a compilation failure which can be used to enforce map updates when address 
spaces are added?

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

@@ -39,7 +39,7 @@ typedef float EmptyArrayTypedef[10][0];
 // CHECK: HLSLResourceClassAttr {{.*}} Implicit CBuffer
 // CHECK: HLSLResourceAttr {{.*}} Implicit CBuffer
 cbuffer CB {
-  // CHECK: VarDecl {{.*}} col:9 used a1 'float'
+  // CHECK: VarDecl {{.*}} col:9 used a1 'hlsl_constant float'

tex3d wrote:

Will this also impact type names in diagnostics?

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [HLSL] Introduce address space `hlsl_constant(2)` for constant buffer declarations (PR #123411)

[Tex Riddell via llvm-branch-commits]

https://github.com/tex3d commented:

I think this looks good, though I had some questions.

Looks like a test update is needed:
```
error: 'expected-error' diagnostics expected but not seen: 
  File 
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-q72qr-1/llvm-project/github-pull-requests/clang/test/SemaTemplate/address_space-dependent.cpp
 Line 46: address space is larger than the maximum supported (8388586)
error: 'expected-error' diagnostics seen but not expected: 
  File 
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-q72qr-1/llvm-project/github-pull-requests/clang/test/SemaTemplate/address_space-dependent.cpp
 Line 46: address space is larger than the maximum supported (8388585)
```

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits