[llvm-branch-commits] [clang] [HLSL] Add RWBuffer::Load(Index) (PR #117018)

2024-11-22 Thread Steven Perron via llvm-branch-commits

https://github.com/s-perron approved this pull request.


https://github.com/llvm/llvm-project/pull/117018
___
llvm-branch-commits mailing list
[email protected]
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)

2025-01-21 Thread Steven Perron via llvm-branch-commits

https://github.com/s-perron approved this pull request.

LGTM. The SPIR-V code seems correct. It would be useful to have a SPIR-V 
specific test.

https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
[email protected]
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)

2025-01-21 Thread Steven Perron via llvm-branch-commits

https://github.com/s-perron edited 
https://github.com/llvm/llvm-project/pull/123411
___
llvm-branch-commits mailing list
[email protected]
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)

2025-01-21 Thread Steven Perron via llvm-branch-commits




s-perron wrote:

Could we add a test for SPIR-V to make sure it gets the correct address space 
as well? They have different target info, so the are different code paths.

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


[llvm-branch-commits] [clang] [HLSL] Tests for local resource arrays (PR #153257)

2025-08-18 Thread Steven Perron via llvm-branch-commits

https://github.com/s-perron approved this pull request.


https://github.com/llvm/llvm-project/pull/153257
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [HLSL] Enable unbounded resource arrays at global scope (PR #155053)

2025-08-26 Thread Steven Perron via llvm-branch-commits


@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.6-compute 
-finclude-default-header \
+// RUN:   -emit-llvm -disable-llvm-passes -o - %s | FileCheck %s 
-check-prefixes=CHECK,DXIL
+// RUN: %clang_cc1 -finclude-default-header -triple 
spirv-unknown-vulkan-compute \
+// RUN:   -emit-llvm -disable-llvm-passes -o - %s | FileCheck %s 
-check-prefixes=CHECK,SPV
+
+// CHECK: @[[BufA:.*]] = private unnamed_addr constant [2 x i8] c"A\00", align 
1
+// CHECK: @[[BufB:.*]] = private unnamed_addr constant [2 x i8] c"B\00", align 
1
+
+RWBuffer A[] : register(u10, space1);
+RWBuffer B[][5][4];
+
+RWStructuredBuffer Out;
+
+float foo(RWBuffer Arr[4], uint Index) {
+  return (float)Arr[Index][0];
+}
+
+// NOTE:
+// - _ZN4hlsl8RWBufferIfEC1EjjijPKc is the constructor call for explicit 
binding for RWBuffer
+//(has "jjij" in the mangled name) and the arguments are (register, space, 
range_size, index, name).
+// - _ZN4hlsl8RWBufferIiEC1EjijjPKc is the constructor call for implicit 
binding for RWBuffer
+//(has "jijj" in the mangled name) and the arguments are (space, 
range_size, index, order_id, name).
+// - _ZN4hlsl8RWBufferIfEixEj is the subscript operator on RWBuffer
+
+[numthreads(4,1,1)]
+void main(uint GI : SV_GroupIndex) {
+  // CHECK: define internal {{.*}}void @_Z4mainj(i32 noundef %GI)
+  // CHECK: %[[GI_alloca:.*]] = alloca i32, align 4
+  // CHECK-NEXT: %a = alloca float, align 4
+  // CHECK-NEXT: %[[Tmp0:.*]] = alloca %"class.hlsl::RWBuffer
+  // CHECK-NEXT: %b = alloca float, align 4
+  // CHECK-NEXT: %[[Tmp1:.*]] = alloca [4 x %"class.hlsl::RWBuffer"]
+  // CHECK-NEXT: %[[Tmp2:.*]] = alloca [4 x %"class.hlsl::RWBuffer"]
+  // CHECK-NEXT: store i32 %GI, ptr %[[GI_alloca]], align 4
+
+  // Make sure A[100] is translated to a RWBuffer constructor call with 
range -1 and index 100

s-perron wrote:

Using `-1` for the range might require special casing in the SPIR-V backend. 
I'll follow up on that later.

https://github.com/llvm/llvm-project/pull/155053
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?=,
Juan Manuel Martinez =?utf-8?q?Caamaño?=,
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 



@@ -43,6 +44,29 @@ bool tryExtendLLVMBitcodeMarker(GlobalVariable &Bitcode) {
   return true;
 }
 
+bool tryExtendDynamicLDSGlobal(GlobalVariable &GV) {
+  constexpr unsigned WorkgroupAS = 3;
+  const bool IsWorkgroupExternal =
+  GV.hasExternalLinkage() && GV.getAddressSpace() == WorkgroupAS;
+  if (!IsWorkgroupExternal)
+return false;
+
+  const ArrayType *AT = dyn_cast(GV.getValueType());
+  if (!AT || AT->getNumElements() != 0)
+return false;

s-perron wrote:

Sorry, I did not write that properly.

Could you have, say, a global whose type is a struct containing a 0-sized 
array? What do you want to do in case?

```
@lds = external addrspace(3) global {i32, [0 x i32]}
```

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 



@@ -52,6 +76,9 @@ bool SPIRVPrepareGlobals::runOnModule(Module &M) {
   if (GlobalVariable *Bitcode = M.getNamedGlobal("llvm.embedded.module"))
 Changed |= tryExtendLLVMBitcodeMarker(*Bitcode);
 
+  for (GlobalVariable &GV : make_early_inc_range(M.globals()))
+Changed |= tryExtendDynamicLDSGlobal(GV);

s-perron wrote:

You can add a comment explaining why yo want to change the type. I'm not 
familiar with`HIP`, and if I was looking at this without looking at the commit 
message I would think it is odd.

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 



@@ -43,6 +44,29 @@ bool tryExtendLLVMBitcodeMarker(GlobalVariable &Bitcode) {
   return true;
 }
 
+bool tryExtendDynamicLDSGlobal(GlobalVariable &GV) {
+  constexpr unsigned WorkgroupAS = 3;
+  const bool IsWorkgroupExternal =
+  GV.hasExternalLinkage() && GV.getAddressSpace() == WorkgroupAS;
+  if (!IsWorkgroupExternal)
+return false;
+
+  const ArrayType *AT = dyn_cast(GV.getValueType());
+  if (!AT || AT->getNumElements() != 0)
+return false;

s-perron wrote:

What do you want to do with 0-sized arrays that are not the type of the global 
value? Is even possible to do that? Comments explaining why you limit this to 
just the type of the GV would be useful.

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 



@@ -43,6 +44,29 @@ bool tryExtendLLVMBitcodeMarker(GlobalVariable &Bitcode) {
   return true;
 }
 
+bool tryExtendDynamicLDSGlobal(GlobalVariable &GV) {
+  constexpr unsigned WorkgroupAS = 3;

s-perron wrote:

It is very unlinkely that this will change, but could this be changed to used 
named constants:

```suggestion
  constexpr unsigned WorkgroupAS = 
storageClassToAddressSpace(SPIRV::StorageClass::Workgroup);
```

It should all get folded at compile time since it is all constexpr.

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 


https://github.com/s-perron edited 
https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 


https://github.com/s-perron commented:

I'm wondering if you need to change all 0-sized array or not. If so, we might 
want to centralize the conversion of 0-sized arrays. We could try to move the 
code that changes them to 1 element arrays here as well.

I can look into changes HLSL use of zero-sized arrays if needed.

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caamaño?=,
Juan Manuel Martinez =?utf-8?q?Caamaño?=,
Juan Manuel Martinez =?utf-8?q?Caamaño?Message-ID:
In-Reply-To: 


s-perron wrote:

> > I'm wondering if you need to change all 0-sized array or not. If so, we 
> > might want to centralize the conversion of 0-sized arrays. We could try to 
> > move the code that changes them to 1 element arrays here as well.
> 
> If you point me to where this is happening I can try to do that too as a 
> follow-up patch.

I was wrong. I was thinking for 
https://github.com/llvm/llvm-project/pull/149522, but that does not changes the 
global variables, it just change the type on the GEP. They seem different 
enough that they may not be reasonable to merge into a single place.

https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [SPIRV][SPIRVPrepareGlobals] Map AMD's dynamic LDS 0-element globals to arrays with UINT32_MAX elements (PR #166952)

2025-11-10 Thread Steven Perron via llvm-branch-commits
Juan Manuel Martinez =?utf-8?q?Caama=C3=B1o?=,
Juan Manuel Martinez =?utf-8?q?Caama=C3=B1o?=,
Juan Manuel Martinez =?utf-8?q?Caama=C3=B1o?=
Message-ID:
In-Reply-To: 


https://github.com/s-perron approved this pull request.


https://github.com/llvm/llvm-project/pull/166952
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits