[clang] [llvm] [DXIL] Set DXIL Version in DXIL target triple based on shader model version (PR #91407)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.

It would be nice to mention in the description what the sanitizer fix was 
compared to the original PR.

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

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[David Peixotto via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: hlsl
+
+#define RS "RootFlags( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | " \ 
+  "DENY_VERTEX_SHADER_ROOT_ACCESS), " \ 
+  "CBV(b0, space = 1, flags = DATA_STATIC), " \ 
+  "SRV(t0), " \ 
+  "UAV(u0), " \ 
+  "DescriptorTable( CBV(b1), " \ 
+  " SRV(t1, numDescriptors = 8, " \ 
+  " flags = DESCRIPTORS_VOLATILE), " \ 
+  " UAV(u1, numDescriptors = unbounded, " \ 
+  " flags = DESCRIPTORS_VOLATILE)), " \ 
+  "DescriptorTable(Sampler(s0, space=1, numDescriptors = 4)), " \ 
+  "RootConstants(num32BitConstants=3, b10), " \ 
+  "StaticSampler(s1)," \ 
+  "StaticSampler(s2, " \ 
+  "  addressU = TEXTURE_ADDRESS_CLAMP, " \ 
+  "  filter = FILTER_MIN_MAG_MIP_LINEAR )"
+
+[RootSignature(RS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+"…"
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? (',' 'flags' '=' 
NUMBER)? ')'
+
+
+SHADER_VISIBILITY : 'SHADER_VISIBILITY_ALL' | 'SHADER_VISIBILITY_VERTEX' | 
+'SHADER_VISIBILITY_HULL' | 
+'SHADER_VISIBILITY_DOMAIN' | 
+'SHADER_VISIBILITY_GEOMETRY' | 
+'SHADER_VISIBILITY_PIXEL' | 
+'SHADER_VISIBILITY_AMPLIFICATION' | 
+'SHADER_VISIBILITY_MESH'
+
+DATA_FLAGS : 

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[David Peixotto via cfe-commits]

dmpots wrote:

I did not see any discussion of local root signatures here. It is probably good 
to consider those as well when thinking about this design. There is alternate 
syntax for specifying both local root signatues and global root signatures 
starting in SM 6.3

https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-state-object

https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-state-object#globalrootsignature
```
GlobalRootSignature MyGlobalRootSignature =
{
"DescriptorTable(UAV(u0))," // Output texture
"SRV(t0),"  // Acceleration structure
"CBV(b0),"  // Scene constants
"DescriptorTable(SRV(t1, numDescriptors = 2))"  // Static index and vertex 
buffers.
};
```

https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-state-object#localrootsignature
```
LocalRootSignature MyLocalRootSignature = 
{
"RootConstants(num32BitConstants = 4, b1)"  // Cube constants 
};
```

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

[clang] [HLSL][Doc] Add doc about expected differences (PR #82395)

[David Peixotto via cfe-commits]

@@ -0,0 +1,108 @@
+
+Expected Differences vs DXC and FXC
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+HLSL currently has two reference compilers, the `DirectX Shader Compiler (DXC)
+`_ and the
+`Effect-Compiler (FXC) 
`_.
+The two reference compilers do not fully agree. Some known disagreements in the
+references are tracked on
+`DXC's GitHub
+`_,
+but many more are known to exist.
+
+HLSL as implemented by Clang will also not fully match either of the reference
+implementations, it is instead being written to match the `draft language
+specification `_.
+
+This document is a non-exhaustive collection the known differences between
+Clang's implementation of HLSL and the existing reference compilers.
+
+General Principles
+--
+
+Most of the intended differences between Clang and the earlier reference
+compilers are focused on increased consistency and correctness. Both reference
+compilers do not always apply language rules the same in all contexts.
+
+Clang also deviates from the reference compilers by providing different
+diagnostics, both in terms of the textual messages and the contexts in which
+diagnostics are produced. While striving for a high level of source
+compatibility with conforming HLSL code, Clang may produce earlier and more
+robust diagnostics for incorrect code or reject code that a reference compiler
+incorrectly accepted.
+
+Language Version
+
+
+Clang targets language compatibility for HLSL 2021 as implemented by DXC.
+Language features that were removed in earlier versions of HLSL may be added on
+a case-by-case basis, but are not planned for the initial implementation.
+
+Overload Resolution
+===
+
+Clang's HLSL implementation adopts C++ overload resolution rules as proposed 
for
+HLSL 202x based on proposal
+`0007 
`_
+and
+`0008 
`_.
+
+Clang's implementation extends standard overload resolution rules to HLSL
+library functionality. This causes subtle changes in overload resolution
+behavior between Clang and DXC. Some examples include:
+
+.. code-block:: c++
+
+  void halfOrInt16(half H);
+  void halfOrInt16(uint16_t I);
+
+  void takesDoubles(double, double, double);
+
+  cbuffer CB {
+uint U;
+uint I;
+float X, Y, Z;
+double3 A, B;
+  }
+
+  export void call() {
+halfOrInt16(U); // All: Resolves to halfOrInt16(uint16_t).
+halfOrInt16(I); // All: Resolves to halfOrInt16(uint16_t).
+  #ifndef IGNORE_ERRORS
+half H = asfloat16(I); // DXC: Fails to resolve overload for int.
+  // Clang: Resolves to halfOrInt16(uint16_t).

dmpots wrote:

Looks like there is a typo in the comment here and a few places below: 
`halfOfInt16` -> `asfloat16`

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

[clang] [HLSL][Doc] Add doc about expected differences (PR #82395)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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

[clang] [HLSL][Doc] Add doc about expected differences (PR #82395)

[David Peixotto via cfe-commits]

https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/82395
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.

LGTM

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -144,6 +144,92 @@ double3 cos(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_cos)
 double4 cos(double4);
 
+//===--===//
+// dot product builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half, half);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half2, half2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half3, half3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half4, half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t, int16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t2, int16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t3, int16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t4, int16_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t, uint16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t2, uint16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t3, uint16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t4, uint16_t4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float, float);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float2, float2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float3, float3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float4, float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double, double);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double2, double2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double3, double3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double4, double4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int, int);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int2, int2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int3, int3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int4, int4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint, uint);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint2, uint2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint3, uint3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint4, uint4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t, int64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t2, int64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t3, int64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t4, int64_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t, uint64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t2, uint64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t3, uint64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t4, uint64_t4);

dmpots wrote:

Why are there no hlsl dot overloads for the 64-bit integer vectors here? The 
32-bit integer vector dot functions also do not map to dxil ops (they are 
expanded to IMad). Since there are no dxil overloads for integer dot it seems 
like we should be consistent in what we support for the hlsl integer overloads.

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -0,0 +1,202 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF

dmpots wrote:

The test looks much better now and makes a lot more sense to me.

I still think we are missing out on opportunities to strengthen our testing. 
The two RUN lines are checking the cases where we have native 16-bit types or 
not. There are many CHECKS here that are only being validated when 16-bit types 
are enabled, but are fully valid when 16-bit types are not enabled.

For example,
```
// CHECK: %dx.dot = mul i32 %0, %1
// CHECK: ret i32 %dx.dot
int test_dot_int ( int p0, int p1 ) {
  return dot ( p0, p1 );
}
```
is equally valid whether 16-bit types are enabled or not, but we only check it 
when 16-bit types are enabled. 

If we used 3 different check prefixes (`CHECK`, `NO_HALF`, `NATIVE_HALF`) then 
it would give better coverage and make it clearer where we expect the 
differences to be.

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

[clang] [HLSL] Expose `half` types and intrinsics always (PR #81782)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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

[clang] [HLSL] Expose `half` types and intrinsics always (PR #81782)

[David Peixotto via cfe-commits]

@@ -42,20 +49,20 @@ int16_t3 abs(int16_t3);
 _HLSL_AVAILABILITY(shadermodel, 6.2)
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t4 abs(int16_t4);
+#endif
 
-_HLSL_AVAILABILITY(shadermodel, 6.2)
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)

dmpots wrote:

Ah ok. So this isn't changing how the enabling of 16bit types are working. It 
just lets the 32-bit half overloads work in earlier shader models.

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

[clang] [HLSL] Expose `half` types and intrinsics always (PR #81782)

[David Peixotto via cfe-commits]

@@ -42,20 +49,20 @@ int16_t3 abs(int16_t3);
 _HLSL_AVAILABILITY(shadermodel, 6.2)
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t4 abs(int16_t4);
+#endif
 
-_HLSL_AVAILABILITY(shadermodel, 6.2)
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)

dmpots wrote:

Currently in dxc the16-bit types are only available when the 
`-enable-16bit-types` command line flag is provided. They are not available by 
default in SM 6.2+.

Is this availability macro making the 16-bit types always available when 
targeting SM 6.2+?

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -0,0 +1,202 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF

dmpots wrote:

I don't think this should be a special case. I think the existing pattern is 
confusing and I would rather not extend it here if not required and I think it 
would be good to update the other tests with something that is better (in my 
opinion).

I am also confused about how this is working. There are a number of test 
functions that are only defined under the `__HLSL_ENABLE_16_BIT` define,

```
#ifdef __HLSL_ENABLE_16_BIT
// CHECK: %dx.dot = mul i16 %0, %1
// CHECK: ret i16 %dx.dot
// NO_HALF: %dx.dot = mul i16 %0, %1
// NO_HALF: ret i16 %dx.dot
int16_t test_dot_short ( int16_t p0, int16_t p1 ) {
  return dot ( p0, p1 );
}
```

That define is only given on the second RUN line, but there are `CHECKS` for 
the first RUN line. How can those checks be passing if that define is not valid?

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -144,6 +144,92 @@ double3 cos(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_cos)
 double4 cos(double4);
 
+//===--===//
+// dot product builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half, half);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half2, half2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half3, half3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half4, half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t, int16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t2, int16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t3, int16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t4, int16_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t, uint16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t2, uint16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t3, uint16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t4, uint16_t4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float, float);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float2, float2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float3, float3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float4, float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double, double);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double2, double2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double3, double3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double4, double4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int, int);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int2, int2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int3, int3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int4, int4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint, uint);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint2, uint2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint3, uint3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint4, uint4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t, int64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t2, int64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t3, int64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t4, int64_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t, uint64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t2, uint64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t3, uint64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t4, uint64_t4);

dmpots wrote:

I am still not clear on exactly which overloads you are proposing that we 
support.

> my preference is to not have overloads that don't lower to DXIL ops

So that would mean no scalar overloads at all (since those lower to multiply) 
and no double overloads. But keep support for i64 and u64 vector overloads?

As for silently generating less efficient code I am somewhat skeptical that 
there is GPU hardware that will accelerate 64-bit dot operations. My guess is 
those all get expanded by the target anyway.

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -verify -verify-ignore-unexpected
+
+float test_first_arg_is_not_vector ( float p0, float2 p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{first two arguments to 'dot' must be vectors}}
+}
+
+float test_second_arg_is_not_vector ( float2 p0, float p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{first two arguments to 'dot' must be vectors}}
+}
+
+int test_dot_unsupported_scalar_arg0 ( bool p0, int p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{1st argument must be a vector, integer or floating 
point type (was 'bool')}}
+}
+
+int test_dot_unsupported_scalar_arg1 ( int p0, bool p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{2nd argument must be a vector, integer or floating 
point type (was 'bool')}}
+}
+
+float test_dot_scalar_mismatch ( float p0, int p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{call to 'dot' is ambiguous}}
+}
+
+float test_dot_vector_size_mismatch ( float3 p0, float2 p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{no matching function for call to 'dot'}}
+}
+
+float test__no_second_arg ( float2 p0) {
+  return dot ( p0 );
+  // expected-error@-1 {{no matching function for call to 'dot'}}
+}
+
+float test_dot_element_type_mismatch ( int2 p0, float2 p1 ) {
+  return dot ( p0, p1 );
+  // expected-error@-1 {{no matching function for call to 'dot'}}

dmpots wrote:

I am a bit surprised by the error here. I would expect `p0` to be promoted to 
`float2` and then call the `dot(float2, float2)` overload.

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -0,0 +1,202 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF

dmpots wrote:

I am having a hard time seeing the difference between the `CHECK` and `NO_HALF` 
checks below. It looks like a lot of them are the same.


>From the command line it looks like the difference is the `-fnative-half-type` 
>flag which means that only the `half` tests should be different. I think in 
>this case it is better to organize the check lines in a way that highlights 
>those differences.

I would suggest using 3 check prefixes like `CHECK`, `NATIVE_HALF`, `NO_HALF`. 
The CHECK prefix will be common to both run lines and the two half ones will 
depend on the native-half-type flag.

```
RUN: clang ... -fnative-half-type ... | FileCheck %s 
-check-prefixes=CHECK,NATIVE_HALF
RUN: clang ...... | FileCheck %s 
-check-prefixes=CHECK,NO_HALF
```

That way you only need to use the NATIVE_HALF and NO_HALF check prefixes when 
there should be actual differences between them.

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -144,6 +144,92 @@ double3 cos(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_cos)
 double4 cos(double4);
 
+//===--===//
+// dot product builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half, half);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half2, half2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half3, half3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half4, half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t, int16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t2, int16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t3, int16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t4, int16_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t, uint16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t2, uint16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t3, uint16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t4, uint16_t4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float, float);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float2, float2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float3, float3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float4, float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double, double);

dmpots wrote:

But dxc does actually accept the double overload for the scalar case only. It 
generates a double multiply in the scalar case so there is no problem with the 
non-existent double overload of the dxil op.

In the vector case it generates a validation error because it tries to use the 
double overload of the dot dxil op.

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -144,6 +144,92 @@ double3 cos(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_cos)
 double4 cos(double4);
 
+//===--===//
+// dot product builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half, half);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half2, half2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half3, half3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half4, half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t, int16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t2, int16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t3, int16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t4, int16_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t, uint16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t2, uint16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t3, uint16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t4, uint16_t4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float, float);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float2, float2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float3, float3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float4, float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double, double);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double2, double2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double3, double3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double4, double4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int, int);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int2, int2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int3, int3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int dot(int4, int4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint, uint);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint2, uint2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint3, uint3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint dot(uint4, uint4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t, int64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t2, int64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t3, int64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int64_t dot(int64_t4, int64_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t, uint64_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t2, uint64_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t3, uint64_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint64_t dot(uint64_t4, uint64_t4);

dmpots wrote:

It looks like dxc accepts the 64-bit overload and generates a dxil op

https://godbolt.org/z/8Gf6xExhc

` %IMad = call i64 @dx.op.tertiary.i64(i32 48, i64 %14, i64 %9, i64 %16)`

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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/81190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -144,6 +144,92 @@ double3 cos(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_cos)
 double4 cos(double4);
 
+//===--===//
+// dot product builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half, half);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half2, half2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half3, half3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+half dot(half4, half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t, int16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t2, int16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t3, int16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+int16_t dot(int16_t4, int16_t4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t, uint16_t);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t2, uint16_t2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t3, uint16_t3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+uint16_t dot(uint16_t4, uint16_t4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float, float);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float2, float2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float3, float3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+float dot(float4, float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_dot)
+double dot(double, double);

dmpots wrote:

I think the double case deserves some discussion about whether this is valid 
hlsl or not. Currently dxc will only accept the `dot(double, double)` overload 
because it happens to lower that to a scalar multiply.

The vector overloads are not supported because there is no double overload of 
the final dxil `dot` intrinsic.


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

[clang] [llvm] [HLSL] Implementation of dot intrinsic (PR #81190)

[David Peixotto via cfe-commits]

@@ -17895,6 +17898,52 @@ llvm::Value 
*CodeGenFunction::EmitScalarOrConstFoldImmArg(unsigned ICEArguments,
   return Arg;
 }
 
+Value *CodeGenFunction::EmitDXILBuiltinExpr(unsigned BuiltinID,
+const CallExpr *E) {
+  switch (BuiltinID) {
+  case Builtin::BI__builtin_hlsl_dot: {
+Value *Op0 = EmitScalarExpr(E->getArg(0));
+Value *Op1 = EmitScalarExpr(E->getArg(1));
+llvm::Type *T0 = Op0->getType();
+llvm::Type *T1 = Op1->getType();
+if (!T0->isVectorTy() && !T1->isVectorTy()) {
+  if (T0->isFloatingPointTy()) {
+return Builder.CreateFMul(Op0, Op1, "dx.dot");
+  }
+
+  if (T0->isIntegerTy()) {
+return Builder.CreateMul(Op0, Op1, "dx.dot");
+  }
+  ErrorUnsupported(
+  E,
+  "Dot product on a scalar is only supported on integers and floats.");
+}
+
+if (T0->isVectorTy() && T1->isVectorTy()) {
+
+  if (T0->getScalarType() != T1->getScalarType()) {
+ErrorUnsupported(E,

dmpots wrote:

I would expect to see tests for these error conditions to exercise this code.

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

[clang] [NFC][HLSL][DX] Update invalid environment tests (PR #81052)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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

[clang] [llvm] [HLSL][DirectX] Move handling of resource element types into the frontend (PR #75674)

[David Peixotto via cfe-commits]

@@ -216,15 +214,62 @@ void 
CGHLSLRuntime::addBufferResourceAnnotation(llvm::GlobalVariable *GV,
 assert(false && "Unsupported buffer type!");
 return;
   }
-
   assert(ResourceMD != nullptr &&
  "ResourceMD must have been set by the switch above.");
 
   llvm::hlsl::FrontendResource Res(
-  GV, TyName, RK, IsROV, Binding.Reg.value_or(UINT_MAX), Binding.Space);
+  GV, RK, ET, IsROV, Binding.Reg.value_or(UINT_MAX), Binding.Space);
   ResourceMD->addOperand(Res.getMetadata());
 }
 
+static llvm::hlsl::ElementType
+calculateElementType(const ASTContext , const clang::Type *ResourceTy) 
{
+  using llvm::hlsl::ElementType;
+
+  // TODO: We may need to update this when we add things like ByteAddressBuffer
+  // that don't have a template parameter (or, indeed, an element type).
+  const auto *TST = ResourceTy->getAs();
+  assert(TST && "Resource types must be template specializations");
+  ArrayRef Args = TST->template_arguments();
+  assert(!Args.empty() && "Resource has no element type");
+
+  // At this point we have a resource with an element type, so we can assume
+  // that it's valid or we would have diagnosed the error earlier.
+  QualType ElTy = Args[0].getAsType();
+
+  // We should either have a basic type or a vector of a basic type.

dmpots wrote:

What about matrix types? Do we need to handle them here as well?

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

[llvm] [clang] [HLSL][DirectX] Move handling of resource element types into the frontend (PR #75674)

[David Peixotto via cfe-commits]

@@ -253,35 +246,6 @@ void UAVResource::print(raw_ostream ) const {
   ResourceBase::print(OS, "U", "u");
 }
 
-// FIXME: Capture this in HLSL source. I would go do this right now, but I want
-// to get this in first so that I can make sure to capture all the extra
-// information we need to remove the source type string from here (See issue:
-// https://github.com/llvm/llvm-project/issues/57991).

dmpots wrote:

Does this PR fix this issue? I did not see it was linked to this PR, but I may 
not be looking in the right place.

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

[clang] [llvm] [HLSL][DirectX] Move handling of resource element types into the frontend (PR #75674)

[David Peixotto via cfe-commits]

https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/75674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [HLSL][DirectX] Move handling of resource element types into the frontend (PR #75674)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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

[clang] [llvm] [DirectX] Move ROV info into HLSL metadata. NFC (PR #74896)

[David Peixotto via cfe-commits]

@@ -219,7 +221,7 @@ void 
CGHLSLRuntime::addBufferResourceAnnotation(llvm::GlobalVariable *GV,
  "ResourceMD must have been set by the switch above.");
 
   llvm::hlsl::FrontendResource Res(
-  GV, TyName, RK, Binding.Reg.value_or(UINT_MAX), Binding.Space);
+  GV, TyName, RK, IsROV, Binding.Reg.value_or(UINT_MAX), Binding.Space);

dmpots wrote:

Ok, sounds good to me. Thanks!

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

[clang] [llvm] [DirectX] Move ROV info into HLSL metadata. NFC (PR #74896)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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

[llvm] [clang] [DirectX] Move ROV info into HLSL metadata. NFC (PR #74896)

[David Peixotto via cfe-commits]

https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/74896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [DirectX] Move ROV info into HLSL metadata. NFC (PR #74896)

[David Peixotto via cfe-commits]

@@ -219,7 +221,7 @@ void 
CGHLSLRuntime::addBufferResourceAnnotation(llvm::GlobalVariable *GV,
  "ResourceMD must have been set by the switch above.");
 
   llvm::hlsl::FrontendResource Res(
-  GV, TyName, RK, Binding.Reg.value_or(UINT_MAX), Binding.Space);
+  GV, TyName, RK, IsROV, Binding.Reg.value_or(UINT_MAX), Binding.Space);

dmpots wrote:

Instead of a single `bool` here it might make sense to have some kind of 
`flags` field that we can extend as needed. I'm wondering what is special about 
ROV that we specifically need to flag them and if that is going to happen to 
other "weird" resource types (like Append/Consume buffers).

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

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[David Peixotto via cfe-commits]

https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/72414
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[David Peixotto via cfe-commits]

@@ -11,557 +11,614 @@
 
 namespace hlsl {
 
-__attribute__((availability(shadermodel, introduced = 6.0)))
-__attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) 
uint
-WaveActiveCountBits(bool bBit);
+// Note: Functions in this file are sorted alphabetically, then grouped by base
+// element type, and the element types are sorted by size, then singed integer,
+// unsigned integer and floating point. Keeping this ordering consistent will
+// help keep this file manageable as it grows.
 
+#define _HLSL_BUILTIN_ALIAS(builtin)   
\

dmpots wrote:

Is it ok to have macros that start with an underscore? I thought identifiers 
starting with _ are reserved in c/c++, but not sure about macros.

Also, since this is a header file should we undef them at the end? Not sure we 
expect others to use the macros themselves, but more of just an implementation 
detail of the header.

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

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[David Peixotto via cfe-commits]

https://github.com/dmpots approved this pull request.


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