[DirectX][SPIRV] Consistent names for HLSL resource intrinsics (#120466)

Rename HLSL resource-related intrinsics to be consistent with the naming
conventions discussed in [wg-hlsl:0014].

This is

[DirectX][SPIRV] Consistent names for HLSL resource intrinsics (#120466)

Rename HLSL resource-related intrinsics to be consistent with the naming
conventions discussed in [wg-hlsl:0014].

This is an entirely mechanical change, consisting of the following
commands and automated formatting.

```sh
git grep -l handle.fromBinding | xargs perl -pi -e \
's/(dx|spv)(.)handle.fromBinding/$1$2resource$2handlefrombinding/g'
git grep -l typedBufferLoad_checkbit | xargs perl -pi -e \
's/(dx|spv)(.)typedBufferLoad_checkbit/$1$2resource$2loadchecked$2typedbuffer/g'
git grep -l typedBufferLoad | xargs perl -pi -e \
's/(dx|spv)(.)typedBufferLoad/$1$2resource$2load$2typedbuffer/g'
git grep -l typedBufferStore | xargs perl -pi -e \
's/(dx|spv)(.)typedBufferStore/$1$2resource$2store$2typedbuffer/g'
git grep -l bufferUpdateCounter | xargs perl -pi -e \
's/(dx|spv)(.)bufferUpdateCounter/$1$2resource$2updatecounter/g'
git grep -l cast_handle | xargs perl -pi -e \
's/(dx|spv)(.)cast.handle/$1$2resource$2casthandle/g'
```

[wg-hlsl:0014]: https://github.com/llvm/wg-hlsl/blob/main/proposals/0014-consistent-naming-for-dx-intrinsics.md

show more ...

[DirectX] Create symbols for resource handles (#119775)

We need to create symbols with "the original shape of resource and
element type" to put in the resource metadata in order to generate valid

[DirectX] Create symbols for resource handles (#119775)

We need to create symbols with "the original shape of resource and
element type" to put in the resource metadata in order to generate valid
DXIL.

Note that DXC generally doesn't emit an actual symbol outside of library
shaders (it emits an undef of a pointer to the type), but since we have
to deal with opaque pointers we would need a way to smuggle the type
through to match that. Instead, we simply emit symbols for now.

Fixed #116849

show more ...

[DirectX] Split resource info into type and binding info. NFC (#119773)

This splits the DXILResourceAnalysis pass into TypeAnalysis and
BindingAnalysis passes. The type analysis pass is made immuta

[DirectX] Split resource info into type and binding info. NFC (#119773)

This splits the DXILResourceAnalysis pass into TypeAnalysis and
BindingAnalysis passes. The type analysis pass is made immutable and
populated lazily so that it can be used earlier in the pipeline without
needing to carefully maintain the invariants of the binding analysis.

Fixes #118400

show more ...

[DirectX] Get resource information via TargetExtType (#119772)

Instead of storing an auxilliary structure with the information from the
DXIL resource target extension types duplicated, access the i

[DirectX] Get resource information via TargetExtType (#119772)

Instead of storing an auxilliary structure with the information from the
DXIL resource target extension types duplicated, access the information
that we can via the type itself.

This also means we need to handle some of the target extension types we
haven't fully defined yet, like Texture and CBuffer. For now we make an
educated guess to what those should look like based on llvm/wg-hlsl#76,
and we can update them fairly easily when we've defined them more
thoroughly.

First part of #118400

show more ...

[DXIL][Analysis] Uniquify duplicate resources in DXILResourceAnalysis

If a resources is used multiple times, we should only have one resource record
for it. This comes up most prominantly with array

[DXIL][Analysis] Uniquify duplicate resources in DXILResourceAnalysis

If a resources is used multiple times, we should only have one resource record
for it. This comes up most prominantly with arrays of resources like so:

```hlsl
RWBuffer<float4> BufferArray[10] : register(u0, space4);
RWBuffer<float4> B1 = BufferArray[0];
RWBuffer<float4> B2 = BufferArray[SomeIndex];
RWBuffer<float4> B3 = BufferArray[3];
```

In this case, there's only one resource, but we'll generate 3 different
`dx.handle.fromBinding` calls to access different slices.

Note that this adds some API that won't be used until #104447 later in the
stack. Trying to avoid that results in unnecessary churn.

Fixes #105143

Pull Request: https://github.com/llvm/llvm-project/pull/105602

show more ...

Re-Apply "[DXIL][Analysis] Implement enough of DXILResourceAnalysis for buffers" (#104517)

Some build configs allow `llvm_unreachable` in a constexpr context, but
not all, so these functions that m

Re-Apply "[DXIL][Analysis] Implement enough of DXILResourceAnalysis for buffers" (#104517)

Some build configs allow `llvm_unreachable` in a constexpr context, but
not all, so these functions that map a fully covered enum to a string
can't be constexpr. This version fixes that by dropping constexpr from
those functions.

This reverts commit fcc318ff7960d7de8cbac56eb4f32b44b5261677, reapplying
28d577ecefa1557f5dea5566bf33b885c563d14b.

Original message follows:

This implements the DXILResourceAnalysis pass for `dx.TypedBuffer` and
`dx.RawBuffer` types. This should be sufficient to lower
`dx.handle.fromBinding` for this set of types, but it leaves a number of
TODOs around for other resource types.

This also includes a straightforward `print` method in `ResourceInfo` to
make the analysis testable. This is deliberately different than the
printer in `lib/Target/DirectX/DXILResource.cpp`, which attempts to
print bindings in a format compatible with the comments `dxc` prints. We
will eventually want to make that functionality driven by this analysis
pass, but it isn't sufficient for testing so we need both.

show more ...

Revert "[DXIL][Analysis] Implement enough of DXILResourceAnalysis for buffers" (#104504)

Reverts llvm/llvm-project#100699

This broke a few bots unfortunately.

[DXIL][Analysis] Implement enough of DXILResourceAnalysis for buffers

This implements the DXILResourceAnalysis pass for `dx.TypedBuffer` and
`dx.RawBuffer` types. This should be sufficient to lower

[DXIL][Analysis] Implement enough of DXILResourceAnalysis for buffers

This implements the DXILResourceAnalysis pass for `dx.TypedBuffer` and
`dx.RawBuffer` types. This should be sufficient to lower
`dx.handle.fromBinding` for this set of types, but it leaves a number
of TODOs around for other resource types.

This also includes a straightforward `print` method in `ResourceInfo`
to make the analysis testable. This is deliberately different than the
printer in `lib/Target/DirectX/DXILResource.cpp`, which attempts to
print bindings in a format compatible with the comments `dxc` prints.
We will eventually want to make that functionality driven by this
analysis pass, but it isn't sufficient for testing so we need both.

Pull Request: https://github.com/llvm/llvm-project/pull/100699

show more ...

[DXIL][Analysis] Boilerplate for DXILResourceAnalysis pass

Broke this out into its own commit to make the next one easier to
review.

Pull Request: https://github.com/llvm/llvm-project/pull/100700

Reapply "[DXIL][Analysis] Make alignment on StructuredBuffer optional" (#101113)

Unfortunately storing a `MaybeAlign` in ResourceInfo deletes our move
constructor in compilers that haven't implemen

Reapply "[DXIL][Analysis] Make alignment on StructuredBuffer optional" (#101113)

Unfortunately storing a `MaybeAlign` in ResourceInfo deletes our move
constructor in compilers that haven't implemented [P0602R4], like GCC 7.
Since we only ever use the alignment in ways where alignment 1 and unset
are ambiguous anyway, we'll just store the integer AlignLog2 value that
we'll eventually use directly.

[P0602R4]:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0602r4.html

This reverts commit c22171f12fa9f260e2525cf61b93c136889e17f2, reapplying
a94edb6b8e321a46fe429934236aaa4e2e9fb97f.

show more ...

Revert "[DXIL][Analysis] Make alignment on StructuredBuffer optional" (#101088)

Seeing build failures, reverting to investigate.

Reverts llvm/llvm-project#100697

[DXIL][Analysis] Make alignment on StructuredBuffer optional

HLSL allows StructuredBuffer<> to be defined with scalar or
up-to-4-element vectors as well as with structs, but when doing so
`dxc` does

[DXIL][Analysis] Make alignment on StructuredBuffer optional

HLSL allows StructuredBuffer<> to be defined with scalar or
up-to-4-element vectors as well as with structs, but when doing so
`dxc` doesn't set the alignment. Emulate this.

Pull Request: https://github.com/llvm/llvm-project/pull/100697

show more ...

[DXIL][Analysis] Use setters for dxil::ResourceInfo initialization. NFC

This simplifies making sure we set all of the members of the unions
and adds asserts to help catch if we do something wrong.

[DXIL][Analysis] Use setters for dxil::ResourceInfo initialization. NFC

This simplifies making sure we set all of the members of the unions
and adds asserts to help catch if we do something wrong.

Pull Request: https://github.com/llvm/llvm-project/pull/100696

show more ...

[DXIL][Analysis] Make the DXILResource binding optional. NFC

This makes the binding structure in a DXILResource default to empty
and need a separate call to set up, and also moves the unique ID into

[DXIL][Analysis] Make the DXILResource binding optional. NFC

This makes the binding structure in a DXILResource default to empty
and need a separate call to set up, and also moves the unique ID into
it since bindings are the only place where those are actually used.

This will put us in a better position when dealing with resource
handles in libraries.

Pull Request: https://github.com/llvm/llvm-project/pull/100623

show more ...

[DXIL][Analysis] Replace #include with forward declaration. NFC

Pull Request: https://github.com/llvm/llvm-project/pull/100622

[DXIL][Analysis] Move dxil::ResourceInfo to the Analysis library. NFC

I had put this in Transforms/Utils, but that doesn't actually make
sense if we want to populate these structures via an analysis

[DXIL][Analysis] Move dxil::ResourceInfo to the Analysis library. NFC

I had put this in Transforms/Utils, but that doesn't actually make
sense if we want to populate these structures via an analysis pass.

Pull Request: https://github.com/llvm/llvm-project/pull/100621

show more ...