<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/122767>122767</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [HLSL] RWBuffer resource variable has external linkage
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            s-perron
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          s-perron
      </td>
    </tr>
</table>

<pre>
    When trying to compile an HLSL file with a resource, the compiler generates a variable to hold the handle to the resource. That variable is not actually the resource, and I believe it should have internal linkage, so that the optimizer could remove all references to it. See https://godbolt.org/z/v559r6axr

```
RWBuffer<int4> buffer : register(u2);

[numthreads(1,1,1)]
void main()
{
    buffer[0] = 0;
}
```

This turns into:

```
@buffer = local_unnamed_addr global %"class.hlsl::RWBuffer" zeroinitializer, align 4, !dbg !0

; Function Attrs: mustprogress nofree noinline norecurse nosync nounwind willreturn memory(write, inaccessiblemem: none)
define void @main() local_unnamed_addr #0 {
  %1 = tail call target("dx.TypedBuffer", <4 x i32>, 1, 0, 0) @llvm.dx.resource.handlefrombinding.tdx.TypedBuffer_v4i32_1_0_0t(i32 0, i32 2, i32 1, i32 0, i1 false), !dbg !45
  store target("dx.TypedBuffer", <4 x i32>, 1, 0, 0) %1, ptr @buffer, align 4, !dbg !45
    #dbg_value(ptr @buffer, !49, !DIExpression(), !54)
    #dbg_value(i32 0, !52, !DIExpression(), !54)
  %2 = tail call noundef nonnull align 16 dereferenceable(16) ptr @llvm.dx.resource.getpointer.p0.tdx.TypedBuffer_v4i32_1_0_0t(target("dx.TypedBuffer", <4 x i32>, 1, 0, 0) %1, i32 0), !dbg !54
  store <4 x i32> zeroinitializer, ptr %2, align 16, !dbg !59, !tbaa !60
  ret void
}
```

Note the store to `@buffer` was not removed. This causes problems for the SPIR-V backend:

1. We cannot remove the store to `@buffer` in the backend because it could be externally visible.
2. SPIR-V has a concept of externally visible variable, but it is not allowed in Vulkan.

Is there anything we can do to allow the optimizer to remove the store?
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJysVk1v2zgT_jX0ZRBBoiR_HHxw4hpvgOLFoi3ao0GJI4lbijRIyo7z6xdDSc7mo7t7KOBEFMV5ZuaZLwrvVWsQt6y8Z5z7uxM6Zw3jnJX7hRhCZ9123l1UVl63Pzo0ENxVmRaChdr2J6URhIH_ff76GRp6uajQgQCH3g6uRsYfIHQ4n3XQokEnAnoQcBZOiUojgXVWy3iyE0aOW_Q24yTwrRPhRUJ5MDaAqMMgtL6-Oks6hZHwCBVqhWcEFcB3dtASOkGvJqAzQoNW5qdoo4AnfSJEIHsKqlfP6KCOQg57e0YQWoPDBh2aGj1ZqEICXxGhC-HkWb5j_MD4obWysjok1rWMH54ZP5zLcuOW4smxdEe_ZTr90t2XH_dD06Bj-YMyoWD5J6jiBrB8Bw5b5QM6xtcDZ3zD8vsJorw3Qx86h0J6xtcZ4w_T34aVe5buzlZJ6IUyjK9pM92xFQkDwKSBlfcpK_fA8j2kE_Jq_8Y-lu6-dcpDGJzxxJwlP9-5wYr0ZvYetK2FPg7GiB7lUUjpoNW2EhoYLxnntRbeJ532msDyFxI4h2d0VhkVlNAUghhMrVoDBS0Zz2TV0mMyjuX3cBhMHZQ1sAvBURygH3w4Ods69JQojUMEY5XRytDCYT04Tyt_NTUYO5iLMhIuSmuH5Cr02Ft3ZXx9cSrEDFFG1DV6ryqNPfakxliDI7cSG4KOpLMifeH9Iy4Yz1OYo8F4mUXSglAaakqyIFyLIcpz-ZR8u55Q3giKLOQPBTyByjnLP9EGhR7S6d-GLND63CfyKbkV0FhXjbN9pYxUpk3Ca-zjuVA5P2bH9JiScpXzEZIWfF5k82L8lEEjtI8kvIpOUUbnfLAOf4M_vIw7p-Dglmm_zIxJN1Gby6o9noUekPH1O2k6O9u9f_z0dKJ0UXaumPFDWYwR_gDwRgMd4_8diPGSvwk5paDEhjLKDFpPjmVLkHhrOdT4qNSXRMnkzLswtxhONja45JT-W4h_W2AmJt4kQVn8LQleQX1U5dEjPvI4u_8Gb8YPlRD0jK0HwGGIlferBvZ_GzA29ikdLdCnWyYsU7iIcZ6MnV7StFEeajF49HBylkreQ2NdhPn6x-OXu-9QifonGnnrh1kCPxBqYV6Q_lmrMvH7hAMVRoU0rca5UyHg0ziq9BXOKraehKU7nsw2dIIGaW1NjacAtvlA4DY0ibxqCIQ_j0-t7QUlGfJ90D-FSUZPHj0Z5mi0X0NH4_4SHQNpyY8o9mZSBvvOZZYfFnKby02-EQvcZqt8udoU5apYdFvOa74W5brGdCkyvtxgisVKrLFueFXVuFBbnvIyzbI8W5fLrEh4WmXpOm-WkpdNWTasSLEXSiexBKxrF8r7AbcZ56vlaqFFhdpPlxuDF4hfp9uN25LQXTW0nmpI-eBfYIIKOt6K6FJD83GeTrcLxss1hOifGZ9vE4vB6e2bG4EK3VAlte0ZP5Ci6XF3cvZPrAPjh2ieZ_ww2X_e8r8CAAD__73j_SU">