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

[Damyan Pepper via cfe-commits]

https://github.com/damyanp 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

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call

damyanp wrote:

typo: `descries` -> `describes`

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

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call

damyanp wrote:

Is this defined behavior that we have to ensure continues to work so HLSL 
developers targeting DXIL can depend on it?

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

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when it is copied back to the argument expression. This is
+undefi

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

damyanp wrote:

This comment just repeats what the code does - and is also pretty redundant 
with the comment on line 4268.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.

I'm worried about what this'll do when `T.isSPIRVLogical()`.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

damyanp wrote:

Shouldn't this check be inside a `T.isDXIL()` block?

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {
+bool LangStdArgIsValid = Opts.LangStd >= LangStandard::lang_hlsl2021;
+bool TPArgIsValid = T.getOSVersion() >= VersionTuple(6, 2);

damyanp wrote:

What does the `TP` prefix mean in this context?

nits on the naming here: neither of these bools really indicate if these 
arguments are "valid".  The first one is "IsAtLeastHLSL2021" and the second is 
"IsAtLeastShaderModel62".  It may even be clearer just to inline these into the 
if condition.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -753,7 +753,8 @@ def err_drv_hlsl_unsupported_target : Error<
   "HLSL code generation is unsupported for target '%0'">;
 def err_drv_hlsl_bad_shader_required_in_target : Error<
   "%select{shader model|Vulkan environment|shader stage}0 is required as 
%select{OS|environment}1 in target '%2' for HLSL code generation">;
-
+def err_drv_hlsl_enable_16bit_types_option_invalid: Error<
+  "enable_16bit_types option only valid when target shader model [-T] is >= 
6.2 and Hlsl Version [-HV] is >= 2021">;

damyanp wrote:

```suggestion
  "enable_16bit_types option only valid when target shader model [-T] is >= 6.2 
and HLSL Version [-HV] is >= 2021">;
```

Looks like "HLSL" is spelled "HLSL" elsewhere.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

damyanp wrote:

Impression I got from the code is that SPIR-V and DXIL use the value returned 
by `T.getOSVersion()` for different things.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

damyanp wrote:

Probably the right thing to do here is figure out what the rules are for SPIR-V 
and get that implemented along with a test.  

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

damyanp wrote:

Should probably have a test in place to ensure that we don't reject any Vulkan 
versions because of -enable-16bit-types being set.

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

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Implement floating literal suffixes (PR #87270)

[Damyan Pepper via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/87270
___
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)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp edited 
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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.


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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,312 @@
+
+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:: c++
+
+#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:: c++
+
+  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:: c++
+
+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 : 'DATA_STATIC_WH

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

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,312 @@
+
+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:: c++
+
+#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:: c++
+
+  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:: c++
+
+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 : 'DATA_STATIC_WH

[clang] [HLSL][docs] Document hlsl.h in the HLSL docs (PR #84081)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL][docs] Document hlsl.h in the HLSL docs (PR #84081)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL][docs] Document hlsl.h in the HLSL docs (PR #84081)

[Damyan Pepper via cfe-commits]

@@ -114,6 +114,44 @@ not re-targetable, we want to share the Clang CodeGen 
implementation for HLSL
 with other GPU graphics targets like SPIR-V and possibly other GPU and even CPU
 targets.
 
+hlsl.h
+--
+
+HLSL has an extensive library of functionality. This is similar to OpenCL and
+CUDA. The implementation approach for the HLSL library functionality draws from
+patterns in use by OpenCL and other Clang resource headers.

damyanp wrote:

Would it be possible to have links to these similar headers for reference?

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

[clang] [HLSL] Add diagnostic for enabling 16 bit types (PR #84537)

[Damyan Pepper via cfe-commits]

@@ -243,6 +243,20 @@ HLSLToolChain::TranslateArgs(const DerivedArgList &Args, 
StringRef BoundArch,
   // FIXME: add validation for enable_16bit_types should be after HLSL 2018 and

damyanp wrote:

Is this FIXME comment outdated by this PR?

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

[clang] [llvm] [HLSL] Implement `rsqrt` intrinsic (PR #84820)

[Damyan Pepper via cfe-commits]

@@ -1153,6 +1153,38 @@ double3 rcp(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_rcp)
 double4 rcp(double4);
 
+//===--===//
+// rsqrt builtins
+//===--===//
+
+/// \fn T rsqrt(T x)
+/// \brief RReturns the reciprocal of the square root of the specified value \a

damyanp wrote:

Comparing this with the doc for rcp above, wonder if it should be more like:

`Returns the reciprocal of the square root of the specified value.  ie 1 / 
sqrt(\a x).`



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

[clang] [llvm] [HLSL] Implement `rsqrt` intrinsic (PR #84820)

[Damyan Pepper via cfe-commits]

@@ -1153,6 +1153,38 @@ double3 rcp(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_rcp)
 double4 rcp(double4);
 
+//===--===//
+// rsqrt builtins
+//===--===//
+
+/// \fn T rsqrt(T x)
+/// \brief RReturns the reciprocal of the square root of the specified value \a

damyanp wrote:

`Rreturns` - typo?

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

[clang] [llvm] [HLSL] Implement `rsqrt` intrinsic (PR #84820)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,49 @@
+; ModuleID = 
'D:\projects\llvm-project\clang\test\SemaHLSL\BuiltIns\dot-warning.hlsl'

damyanp wrote:

Maybe naive question...but isn't this about the `dot` intrinsic?

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

[clang] [llvm] [HLSL] Implement `rsqrt` intrinsic (PR #84820)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,27 @@
+
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -fnative-half-type -emit-llvm 
-disable-llvm-passes -verify -verify-ignore-unexpected
+
+float test_too_few_arg() {
+  return __builtin_hlsl_elementwise_rsqrt();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 
0}}
+}
+
+float2 test_too_many_arg(float2 p0) {
+  return __builtin_hlsl_elementwise_rsqrt(p0, p0);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 
2}}
+}
+
+float builtin_bool_to_float_type_promotion(bool p1) {
+  return __builtin_hlsl_elementwise_rsqrt(p1);
+  // expected-error@-1 {{1st argument must be a vector, integer or floating 
point type (was 'bool')}}

damyanp wrote:

"integer" - is this true?  I thought it only worked with things that were 
float-like.

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

[clang] [llvm] [HLSL] Implement `rsqrt` intrinsic (PR #84820)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Fix casting asserts (PR #82827)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] standardize builtin unit tests (PR #83340)

[Damyan Pepper via cfe-commits]

damyanp wrote:

> Do we have the suggestions that this is responding to written down somewhere? 
> I think it would be useful to have those guidelines for anyone who might want 
> to contribute HLSL tests. At any rate, I'd like to know the ones that this is 
> in response to.

Following on from this, how would someone reproduce the clang formatting you 
got here?  It sounds like you had to explicitly turn off comment reflowing to 
make it work as intended?

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

[clang] [HLSL] standardize builtin unit tests (PR #83340)

[Damyan Pepper via cfe-commits]

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


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

[clang] [llvm] [HLSL][DXIL] Implementation of round intrinsic (PR #83570)

[Damyan Pepper via cfe-commits]

damyanp wrote:

> This chane reuses llvms existing intrinsic `__builtin_elementwise_round`\ 
> `int_round`

I suspect a typo - `chane` -> `change`?



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

[clang] [llvm] [HLSL][DXIL] Implementation of round intrinsic (PR #83570)

[Damyan Pepper via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/83570
___
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)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp edited 
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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++

damyanp wrote:

This code block doesn't render at all (eg in the preview when viewing this 
file).

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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]

damyanp wrote:

It would be nice to see a more complete example in here that specifies a root 
signature.  I think that the `MyRS1` thing only works from the example in the 
docs because there's a `#define MyRS1 "..."` earlier on in the example.  Does 
`MyRS1` really mean anything special to the compiler?

It looks like there's some special rules around the `-T rootsig_1_1` case that 
applies special meaning to "Entry Point" and assumptions about preprocessor 
defines, but the `RootSignature` attribute itself in source code just takes a 
string.

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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++
+  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:: c++
+
+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 : 'DATA_STATIC_WHILE_SET_AT_EXECUTE' | 'DATA_VOLATILE'
+
+DESCRIPTOR_RANGE_OFFSET : 'DESCRIPTOR_RANGE_OFFSET_APPEND' | NUMBER
+
+StaticSampler : 'StaticSampler' '(' sReg (',' 'filter' '=' FILTER)? (',' 
'addressU' '=' TEXTURE_ADDRESS)? (',' 'addressV' '=' TEXTURE_ADDRESS)? (',' 
'addressW' '=' TEXTURE_ADDRESS)? (',' 'mipLODBias' '=' NUMBER)? (',' 
'maxAnisotropy' '=' NUMBER)? (',' 'comparisonFunc' '=' COMPARISON_FUNC)? (',' 
'borderColor' '=' STATIC_BORDER_COLOR)? (',' 'minLOD' '=' NUMBER)? (',' 
'maxLOD' '=' NUMBER)? (',' 'space' '=' NUMBER)? (',' 'visibility' '=' 
SHADER_VISIBILITY)? ')'
+
+bReg : 'b' NUMBER 
+
+tReg : 't' NUMBER 
+
+uReg : 'u' NUMBER 
+
+sReg : 's' NUMBER 
+
+FILTER : 'FILTER_MIN_MAG_MIP_POINT' | 'FILTER_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_MIN_LINEAR_MAG_MIP_POINT' | 'FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_MAG_MIP_LINEAR' | 
'FILTER_ANISOTROPIC' | 'FILTER_COMPARISON_MIN_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_POINT_MAG_LINEAR_MIP_POINT' | 
'FILTER_COMPARISON_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_MAG_LINEA

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

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.


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] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++
+  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:: c++
+
+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 : 'DATA_STATIC_WHILE_SET_AT_EXECUTE' | 'DATA_VOLATILE'
+
+DESCRIPTOR_RANGE_OFFSET : 'DESCRIPTOR_RANGE_OFFSET_APPEND' | NUMBER
+
+StaticSampler : 'StaticSampler' '(' sReg (',' 'filter' '=' FILTER)? (',' 
'addressU' '=' TEXTURE_ADDRESS)? (',' 'addressV' '=' TEXTURE_ADDRESS)? (',' 
'addressW' '=' TEXTURE_ADDRESS)? (',' 'mipLODBias' '=' NUMBER)? (',' 
'maxAnisotropy' '=' NUMBER)? (',' 'comparisonFunc' '=' COMPARISON_FUNC)? (',' 
'borderColor' '=' STATIC_BORDER_COLOR)? (',' 'minLOD' '=' NUMBER)? (',' 
'maxLOD' '=' NUMBER)? (',' 'space' '=' NUMBER)? (',' 'visibility' '=' 
SHADER_VISIBILITY)? ')'
+
+bReg : 'b' NUMBER 
+
+tReg : 't' NUMBER 
+
+uReg : 'u' NUMBER 
+
+sReg : 's' NUMBER 
+
+FILTER : 'FILTER_MIN_MAG_MIP_POINT' | 'FILTER_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_MIN_LINEAR_MAG_MIP_POINT' | 'FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_MAG_MIP_LINEAR' | 
'FILTER_ANISOTROPIC' | 'FILTER_COMPARISON_MIN_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_POINT_MAG_LINEAR_MIP_POINT' | 
'FILTER_COMPARISON_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_MAG_LINEA

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

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++
+  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:: c++
+
+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 : 'DATA_STATIC_WHILE_SET_AT_EXECUTE' | 'DATA_VOLATILE'
+
+DESCRIPTOR_RANGE_OFFSET : 'DESCRIPTOR_RANGE_OFFSET_APPEND' | NUMBER
+
+StaticSampler : 'StaticSampler' '(' sReg (',' 'filter' '=' FILTER)? (',' 
'addressU' '=' TEXTURE_ADDRESS)? (',' 'addressV' '=' TEXTURE_ADDRESS)? (',' 
'addressW' '=' TEXTURE_ADDRESS)? (',' 'mipLODBias' '=' NUMBER)? (',' 
'maxAnisotropy' '=' NUMBER)? (',' 'comparisonFunc' '=' COMPARISON_FUNC)? (',' 
'borderColor' '=' STATIC_BORDER_COLOR)? (',' 'minLOD' '=' NUMBER)? (',' 
'maxLOD' '=' NUMBER)? (',' 'space' '=' NUMBER)? (',' 'visibility' '=' 
SHADER_VISIBILITY)? ')'
+
+bReg : 'b' NUMBER 
+
+tReg : 't' NUMBER 
+
+uReg : 'u' NUMBER 
+
+sReg : 's' NUMBER 
+
+FILTER : 'FILTER_MIN_MAG_MIP_POINT' | 'FILTER_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_MIN_LINEAR_MAG_MIP_POINT' | 'FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_MAG_MIP_LINEAR' | 
'FILTER_ANISOTROPIC' | 'FILTER_COMPARISON_MIN_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_POINT_MAG_LINEAR_MIP_POINT' | 
'FILTER_COMPARISON_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_MAG_LINEA

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

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++
+  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:: c++
+
+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 : 'DATA_STATIC_WHILE_SET_AT_EXECUTE' | 'DATA_VOLATILE'
+
+DESCRIPTOR_RANGE_OFFSET : 'DESCRIPTOR_RANGE_OFFSET_APPEND' | NUMBER
+
+StaticSampler : 'StaticSampler' '(' sReg (',' 'filter' '=' FILTER)? (',' 
'addressU' '=' TEXTURE_ADDRESS)? (',' 'addressV' '=' TEXTURE_ADDRESS)? (',' 
'addressW' '=' TEXTURE_ADDRESS)? (',' 'mipLODBias' '=' NUMBER)? (',' 
'maxAnisotropy' '=' NUMBER)? (',' 'comparisonFunc' '=' COMPARISON_FUNC)? (',' 
'borderColor' '=' STATIC_BORDER_COLOR)? (',' 'minLOD' '=' NUMBER)? (',' 
'maxLOD' '=' NUMBER)? (',' 'space' '=' NUMBER)? (',' 'visibility' '=' 
SHADER_VISIBILITY)? ')'
+
+bReg : 'b' NUMBER 
+
+tReg : 't' NUMBER 
+
+uReg : 'u' NUMBER 
+
+sReg : 's' NUMBER 
+
+FILTER : 'FILTER_MIN_MAG_MIP_POINT' | 'FILTER_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_MIN_LINEAR_MAG_MIP_POINT' | 'FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_MAG_MIP_LINEAR' | 
'FILTER_ANISOTROPIC' | 'FILTER_COMPARISON_MIN_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_POINT_MAG_LINEAR_MIP_POINT' | 
'FILTER_COMPARISON_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_MAG_LINEA

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

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,210 @@
+
+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:: c++
+
+[RootSignature(MyRS1)]
+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:: c++
+  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:: c++
+
+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 : 'DATA_STATIC_WHILE_SET_AT_EXECUTE' | 'DATA_VOLATILE'
+
+DESCRIPTOR_RANGE_OFFSET : 'DESCRIPTOR_RANGE_OFFSET_APPEND' | NUMBER
+
+StaticSampler : 'StaticSampler' '(' sReg (',' 'filter' '=' FILTER)? (',' 
'addressU' '=' TEXTURE_ADDRESS)? (',' 'addressV' '=' TEXTURE_ADDRESS)? (',' 
'addressW' '=' TEXTURE_ADDRESS)? (',' 'mipLODBias' '=' NUMBER)? (',' 
'maxAnisotropy' '=' NUMBER)? (',' 'comparisonFunc' '=' COMPARISON_FUNC)? (',' 
'borderColor' '=' STATIC_BORDER_COLOR)? (',' 'minLOD' '=' NUMBER)? (',' 
'maxLOD' '=' NUMBER)? (',' 'space' '=' NUMBER)? (',' 'visibility' '=' 
SHADER_VISIBILITY)? ')'
+
+bReg : 'b' NUMBER 
+
+tReg : 't' NUMBER 
+
+uReg : 'u' NUMBER 
+
+sReg : 's' NUMBER 
+
+FILTER : 'FILTER_MIN_MAG_MIP_POINT' | 'FILTER_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_MIN_LINEAR_MAG_MIP_POINT' | 'FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_MIN_MAG_LINEAR_MIP_POINT' | 'FILTER_MIN_MAG_MIP_LINEAR' | 
'FILTER_ANISOTROPIC' | 'FILTER_COMPARISON_MIN_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_POINT_MAG_LINEAR_MIP_POINT' | 
'FILTER_COMPARISON_MIN_POINT_MAG_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_MIP_POINT' | 
'FILTER_COMPARISON_MIN_LINEAR_MAG_POINT_MIP_LINEAR' | 
'FILTER_COMPARISON_MIN_MAG_LINEA

[clang] [Windows] Add git-clang-format wrapper bat file (PR #69228)

[Damyan Pepper via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/69228
___
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)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp 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] Rework implicit conversion sequences (PR #96011)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Implement `export` keyword (PR #96823)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Implement `export` keyword (PR #96823)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Implement `export` keyword (PR #96823)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,56 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - %s 
-verify
+
+export void f1();
+
+export void f1() {}
+
+namespace { // expected-note {{anonymous namespace begins here}}
+export void f2(); // expected-error {{export declaration appears within 
anonymous namespace}}
+}
+
+export void f3();
+
+export { // expected-note {{export block begins here}}
+void f4() {}
+export void f5() {} // expected-error {{export declaration appears within 
another export declaration}}

damyanp wrote:

What's the rationale for prohibiting nested exports?

I notice that C++ allows nested `extern 'C'`s, for example.

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

[clang] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -437,7 +460,206 @@ void SemaHLSL::handleShaderAttr(Decl *D, const ParsedAttr 
&AL) {
 D->addAttr(NewAttr);
 }
 
+struct register_binding_flags {
+  bool resource = false;
+  bool udt = false;
+  bool other = false;
+  bool basic = false;
+
+  bool srv = false;
+  bool uav = false;
+  bool cbv = false;
+  bool sampler = false;
+
+  bool contains_numeric = false;
+  bool default_globals = false;
+};
+
+bool isDeclaredWithinCOrTBuffer(const Decl *decl) {
+  if (!decl)
+return false;
+
+  // Traverse up the parent contexts
+  const DeclContext *context = decl->getDeclContext();
+  while (context) {
+if (isa(context)) {
+  return true;
+}
+context = context->getParent();
+  }
+
+  return false;
+}
+
+const HLSLResourceAttr *
+getHLSLResourceAttrFromVarDecl(VarDecl *SamplerUAVOrSRV) {
+  const Type *Ty = SamplerUAVOrSRV->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+llvm_unreachable("Resource class must have an element type.");
+
+  if (const BuiltinType *BTy = dyn_cast(Ty)) {
+/* QualType QT = SamplerUAVOrSRV->getType();
+PrintingPolicy PP = S.getPrintingPolicy();
+std::string typestr = QualType::getAsString(QT.split(), PP);
+
+S.Diag(ArgLoc, diag::err_hlsl_unsupported_register_resource_type)
+<< typestr;
+return; */
+return nullptr;
+  }
+
+  const CXXRecordDecl *TheRecordDecl = Ty->getAsCXXRecordDecl();
+  if (!TheRecordDecl)
+llvm_unreachable("Resource class should have a resource type 
declaration.");
+
+  if (auto TDecl = dyn_cast(TheRecordDecl))
+TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+  const auto *Attr = TheRecordDecl->getAttr();
+  return Attr;
+}
+
+void traverseType(QualType T, register_binding_flags &r) {
+  if (T->isIntegralOrEnumerationType() || T->isFloatingType()) {
+r.contains_numeric = true;
+return;
+  } else if (const RecordType *RT = T->getAs()) {
+RecordDecl *SubRD = RT->getDecl();
+if (auto TDecl = dyn_cast(SubRD)) {
+  auto TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+  const auto *Attr = TheRecordDecl->getAttr();
+  llvm::hlsl::ResourceClass DeclResourceClass = Attr->getResourceClass();
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+r.srv = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+r.uav = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+r.cbv = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::Sampler: {
+r.sampler = true;
+break;
+  }
+  }
+}
+
+else if (SubRD->isCompleteDefinition()) {
+  for (auto Field : SubRD->fields()) {
+QualType T = Field->getType();
+traverseType(T, r);
+  }
+}
+  }
+}
+
+void setResourceClassFlagsFromRecordDecl(register_binding_flags &r,
+ const RecordDecl *RD) {
+  if (!RD)
+return;
+
+  if (RD->isCompleteDefinition()) {
+for (auto Field : RD->fields()) {
+  QualType T = Field->getType();

damyanp wrote:

I thought that the plan for this was that it would be a warning, not an error?

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

[clang] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.

I'm a bit confused by this change.  It seems that some tweaks have been made to 
the diagnostics, and something code around register_binding_flags has been 
added, but doesn't seem to be tested at all.

It seems it should be possible to slice this so that changes do come in with 
tests and aren't entirely around anticipating future functionality.

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

[clang] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -437,7 +460,206 @@ void SemaHLSL::handleShaderAttr(Decl *D, const ParsedAttr 
&AL) {
 D->addAttr(NewAttr);
 }
 
+struct register_binding_flags {
+  bool resource = false;
+  bool udt = false;
+  bool other = false;
+  bool basic = false;
+
+  bool srv = false;
+  bool uav = false;
+  bool cbv = false;
+  bool sampler = false;
+
+  bool contains_numeric = false;
+  bool default_globals = false;
+};
+
+bool isDeclaredWithinCOrTBuffer(const Decl *decl) {
+  if (!decl)
+return false;
+
+  // Traverse up the parent contexts
+  const DeclContext *context = decl->getDeclContext();
+  while (context) {
+if (isa(context)) {
+  return true;
+}
+context = context->getParent();
+  }
+
+  return false;
+}
+
+const HLSLResourceAttr *
+getHLSLResourceAttrFromVarDecl(VarDecl *SamplerUAVOrSRV) {
+  const Type *Ty = SamplerUAVOrSRV->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+llvm_unreachable("Resource class must have an element type.");
+
+  if (const BuiltinType *BTy = dyn_cast(Ty)) {
+/* QualType QT = SamplerUAVOrSRV->getType();
+PrintingPolicy PP = S.getPrintingPolicy();
+std::string typestr = QualType::getAsString(QT.split(), PP);
+
+S.Diag(ArgLoc, diag::err_hlsl_unsupported_register_resource_type)
+<< typestr;
+return; */
+return nullptr;
+  }
+
+  const CXXRecordDecl *TheRecordDecl = Ty->getAsCXXRecordDecl();
+  if (!TheRecordDecl)
+llvm_unreachable("Resource class should have a resource type 
declaration.");
+
+  if (auto TDecl = dyn_cast(TheRecordDecl))
+TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+  const auto *Attr = TheRecordDecl->getAttr();
+  return Attr;
+}
+
+void traverseType(QualType T, register_binding_flags &r) {
+  if (T->isIntegralOrEnumerationType() || T->isFloatingType()) {
+r.contains_numeric = true;
+return;
+  } else if (const RecordType *RT = T->getAs()) {
+RecordDecl *SubRD = RT->getDecl();
+if (auto TDecl = dyn_cast(SubRD)) {
+  auto TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+  const auto *Attr = TheRecordDecl->getAttr();
+  llvm::hlsl::ResourceClass DeclResourceClass = Attr->getResourceClass();
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+r.srv = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+r.uav = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+r.cbv = true;
+break;
+  }
+  case llvm::hlsl::ResourceClass::Sampler: {
+r.sampler = true;
+break;
+  }
+  }
+}
+
+else if (SubRD->isCompleteDefinition()) {
+  for (auto Field : SubRD->fields()) {
+QualType T = Field->getType();
+traverseType(T, r);
+  }
+}
+  }
+}
+
+void setResourceClassFlagsFromRecordDecl(register_binding_flags &r,
+ const RecordDecl *RD) {
+  if (!RD)
+return;
+
+  if (RD->isCompleteDefinition()) {
+for (auto Field : RD->fields()) {
+  QualType T = Field->getType();
+  traverseType(T, r);
+}
+  }
+}
+
+register_binding_flags HLSLFillRegisterBindingFlags(Sema &S, Decl *D) {

damyanp wrote:

How is this tested?

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

[clang] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

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

[clang] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -12303,7 +12303,10 @@ def err_hlsl_missing_semantic_annotation : Error<
 def err_hlsl_init_priority_unsupported : Error<
   "initializer priorities are not supported in HLSL">;
 
-def err_hlsl_unsupported_register_type : Error<"invalid resource class 
specifier '%0' used; expected 'b', 's', 't', or 'u'">;
+def err_hlsl_mismatching_register_resource_type_and_name: Error<"invalid 
register name prefix '%0' for register resource type '%1' (expected 
%select{'t'|'u'|'b'|'s'}2)">;
+def err_hlsl_mismatching_register_builtin_type_and_name: Error<"invalid 
register name prefix '%0' for '%1' (expected %2)">;
+def err_hlsl_unsupported_register_prefix : Error<"invalid resource class 
specifier '%0' used; expected 't', 'u', 'b', or 's'">;
+def err_hlsl_unsupported_register_resource_type : Error<"invalid resource '%0' 
used">;

damyanp wrote:

I only see `err_hlsl_unsupported_register_prefix` referenced in the code.  
`err_hlsl_unsupported_register_resource_type` is in some code that's commented 
out.  The two mismatching ones don't appear in the code at all.

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

[clang] [HLSL] Run availability diagnostic on exported functions (PR #97352)

[Damyan Pepper via cfe-commits]

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


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

[clang] [lldb] [HLSL] Implement intangible AST type (PR #97362)

[Damyan Pepper via cfe-commits]

@@ -115,6 +116,18 @@ GlobalVariable *replaceBuffer(CGHLSLRuntime::Buffer &Buf) {
 
 } // namespace
 
+llvm::Type *CGHLSLRuntime::convertHLSLSpecificType(const Type *T) {
+  assert(T->isHLSLSpecificType() && "Not an HLSL specific type!");
+
+  // Check if the target has a specific translation for this type first.
+  if (llvm::Type *TargetTy = CGM.getTargetCodeGenInfo().getHLSLType(CGM, T))
+return TargetTy;
+
+  // TODO: What do we actually want to do generically here? OpenCL uses a
+  // pointer in a particular address space.
+  llvm_unreachable("Generic handling of HLSL types is not implemented yet");

damyanp wrote:

At what point will this become something we need to do?  Is there an issue 
tracking it?

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

[clang] [lldb] [HLSL] Implement intangible AST type (PR #97362)

[Damyan Pepper via cfe-commits]

damyanp wrote:

I see many places where extra cases have been added for the intangible types 
but no corresponding tests.  Is that ok?  How did you know to update these 
places?

I also don't see anywhere that actually successfully uses 
`__builtin_hlsl_resource_t`. Am I missing it, or should I not expect to see it?

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

[clang-tools-extra] Fix Default Asset File locator for clang docs (PR #97505)

[Damyan Pepper via cfe-commits]

damyanp wrote:

I don't think that the current description matches the change?

Does this mean that there'll likely be 3 copies of each file.  One per 
configuration, and another copy just in the binary directory?

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

[clang-tools-extra] Fix Default Asset File locator for clang docs (PR #97505)

[Damyan Pepper via cfe-commits]

@@ -44,7 +42,10 @@ foreach(f ${assets})
   install(FILES ${asset_dir}/${f}
 DESTINATION "${CMAKE_INSTALL_DATADIR}/clang-doc"
 COMPONENT clang-doc)
-  copy_files_to_dst(${asset_dir} ${resource_dir} ${f})
+   foreach(config ${CMAKE_CONFIGURATION_TYPES})

damyanp wrote:

Do ninja / other single-config build systems still work?  I think that 
`CMAKE_CONFIGURATION_TYPES` is blank for single configuration systems.

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,76 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -o - | FileCheck %s --check-prefixes=CHECK
+
+// CHECK: %hlsl.select = select i1
+// CHECK: ret i32 %hlsl.select
+int test_select_bool_int(bool cond0, int tVal, int fVal) { return 
select(cond0, tVal, fVal); }

damyanp wrote:

nit: https://llvm.org/docs/CodingStandards.html#source-code-width

these would be easier to read in the github PR UI if it were formatted to 80 
columns.

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

@@ -1544,6 +1604,30 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
   return true;
 break;
   }
+  case Builtin::BI__builtin_hlsl_select: {

damyanp wrote:

This implementation has quite a different shape to the other builtins in this 
function.  I'm trying to figure out if there's something special about `select` 
that makes this necessary, or if this validation can be expressed using the 
existing CheckXXX functions in here.

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -emit-llvm-only -disable-llvm-passes -verify 
-verify-ignore-unexpected
+
+int test_no_arg() {
+  return select();
+  // expected-error@-1 {{no matching function for call to 'select'}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 0 were provided}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 0 were provided}}
+}
+
+int test_too_few_args(bool p0) {
+  return select(p0);
+  // expected-error@-1 {{no matching function for call to 'select'}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 1 was provided}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 1 was provided}}
+}
+
+int test_too_many_args(bool p0, int t0, int f0, int g0) {
+  return select(p0, t0, f0, g0);
+  // expected-error@-1 {{no matching function for call to 'select'}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 4 were provided}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: requires 3 arguments, but 4 were provided}}
+}
+
+int test_select_first_arg_wrong_type(vector p0, int t0, int f0) {
+  return select(p0, t0, f0);
+  // expected-error@-1 {{no matching function for call to 'select'}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate function template not 
viable: no known conversion from 'vector' (vector of 1 'int' value) to 
'bool' for 1st argument}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate template ignored: 
could not match 'vector' against 'int'}}
+}
+
+vector test_select_bool_vals_diff_vecs(bool p0, vector t0, 
vector f0) {
+  return select >(p0, t0, f0);
+  // expected-warning@-1 {{implicit conversion truncates vector: 'vector' (vector of 2 'int' values) to 'vector' (vector of 1 'int' value)}}
+}
+
+vector test_select_vector_vals_not_vecs(vector p0, int t0, int 
f0) {
+  return select(p0, t0, f0);
+  // expected-error@-1 {{no matching function for call to 'select'}}
+  // expected-note@hlsl/hlsl_intrinsics.h:* {{candidate template ignored: 
could not match 'vector' against 'int'}}

damyanp wrote:

I'm looking at some of these errors here and wondering if you've managed to 
actually exercise all of the diagnostics emitted from SemaHLSL?  I think that 
most of these diagnostics are actually caught by standard C++ rules for 
function lookup.

I wonder if some tests that directly call `__builtin_hlsl_select` with invalid 
parameters are really required here to have complete coverage?

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

@@ -1544,6 +1604,30 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
   return true;
 break;
   }
+  case Builtin::BI__builtin_hlsl_select: {
+if (SemaRef.checkArgCount(TheCall, 3))
+  return true;
+QualType ArgTy = TheCall->getArg(0)->getType();
+if (ArgTy->isBooleanType()) {
+  if (CheckBoolSelect(&SemaRef, TheCall))
+   return true;
+} else if (ArgTy->isVectorType() &&
+  ArgTy->getAs()->getElementType()->isBooleanType()) {
+  if (CheckVectorSelect(&SemaRef, TheCall))
+   return true;
+} else { // first operand is not a bool or a vector of bools.
+  SemaRef.Diag(TheCall->getArg(0)->getBeginLoc(),
+  diag::err_typecheck_convert_incompatible)
+   << TheCall->getArg(0)->getType() << getASTContext().BoolTy
+   << 1 << 0 << 0;
+  SemaRef.Diag(TheCall->getArg(0)->getBeginLoc(),
+  diag::err_builtin_non_vector_type)
+   << "First" << "__builtin_hlsl_select" << TheCall->getArg(0)->getType()
+   << TheCall->getArg(0)->getSourceRange();
+  return true;

damyanp wrote:

Wondering why this case doesn't also use a helper function and instead inlines 
the detection and diagnostic code here.

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

@@ -1512,6 +1512,66 @@ void SetElementTypeAsReturnType(Sema *S, CallExpr 
*TheCall,
   TheCall->setType(ReturnType);
 }
 
+bool CheckBoolSelect(Sema *S, CallExpr *TheCall) {

damyanp wrote:

nit: it'd be good for these helpers that are only used from this cpp file to be 
marked as static.  (I see that the ones above are not marked as static...I'd be 
tempted to fix them as well in another PR).

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

@@ -77,6 +77,23 @@ class SemaHLSL : public SemaBase {
   ExprResult ActOnOutParamExpr(ParmVarDecl *Param, Expr *Arg);
 
   QualType getInoutParameterType(QualType Ty);
+
+  // FIXME: This can be hidden (as static function in SemaHLSL.cpp) once we no
+  // longer need to create builtin buffer types in HLSLExternalSemaSource.

damyanp wrote:

Does this need to be a static member of SemaHLSL?  It sounds like it doesn't if 
we think it can be trivially made a file static.

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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp commented:

Typo in description:

> Converts existing resource attributes [[hlsl::resource_class(..)]] and 
> [[is_rov]] ~~to~~ from declaration attributes to type attributes.


There's many places in the existing tests where these attributes are being used 
in ways we don't really intend them to use.  Maybe now would be the right time 
to fix them up?



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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

@@ -1,32 +1,32 @@
 // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -ast-dump -o 
- %s | FileCheck %s
 
-
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  SRV
-struct Eg1 {
-  [[hlsl::resource_class(SRV)]] int i;  
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}} {{.*}} struct MyBuffer definition
+// CHECK: FieldDecl 0x{{[0-9a-f]+}}  col:51 h 
'__hlsl_resource_t {{\[\[}}hlsl::resource_class(UAV)]]':'__hlsl_resource_t'
+struct MyBuffer {
+  __hlsl_resource_t [[hlsl::resource_class(UAV)]] h;
 };
 
-Eg1 e1;
-
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:13:8 
referenced struct Eg2 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  UAV
-struct Eg2 {
-  [[hlsl::resource_class(UAV)]] int i;
-};
-Eg2 e2;
+// CHECK: VarDecl 0x{{[0-9a-f]+}}  col:49 res 
'__hlsl_resource_t {{\[\[}}hlsl::resource_class(SRV)]]':'__hlsl_resource_t'
+__hlsl_resource_t [[hlsl::resource_class(SRV)]] res;
 
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:20:8 
referenced struct Eg3 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  CBuffer
-struct Eg3 {
-  [[hlsl::resource_class(CBuffer)]] int i;
-}; 
-Eg3 e3;
+// CHECK: FunctionDecl 0x{{[0-9a-f]+}}  line:14:6 f 
'void ()
+// CHECK: VarDecl 0x{{[0-9a-f]+}}  col:55 r '__hlsl_resource_t 
{{\[\[}}hlsl::resource_class(Sampler)]]':'__hlsl_resource_t'
+void f() {
+  __hlsl_resource_t [[hlsl::resource_class(Sampler)]] r;
+}
 
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:27:8 
referenced struct Eg4 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  Sampler
-struct Eg4 {
-  [[hlsl::resource_class(Sampler)]] int i;
+// CHECK: ClassTemplateDecl 0x{{[0-9a-f]+}}  line:23:29 
MyBuffer2
+// CHECK: TemplateTypeParmDecl 0x{{[0-9a-f]+}}  col:19 
referenced typename depth 0 index 0 T
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}}  line:23:29 struct 
MyBuffer2 definition
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}}  col:29 implicit 
struct MyBuffer2
+// CHECK: FieldDecl 0x{{[0-9a-f]+}}  col:35 h 'T 
{{\[\[}}hlsl::resource_class(UAV)]]':'T'
+template struct MyBuffer2 {
+  T [[hlsl::resource_class(UAV)]] h;

damyanp wrote:

Do we have special code supporting this scenario? Because I don't think it is 
one that we'd ever want to support.  `h` should be a handle type, whereas `T` 
here is strongly suggested to be the element type of the buffer.

`myBuffer2` below at least should using something more handle-type like.

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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

@@ -556,46 +562,120 @@ void SemaHLSL::handleShaderAttr(Decl *D, const 
ParsedAttr &AL) {
 D->addAttr(NewAttr);
 }
 
-void SemaHLSL::handleResourceClassAttr(Decl *D, const ParsedAttr &AL) {
-  if (!AL.isArgIdent(0)) {
-Diag(AL.getLoc(), diag::err_attribute_argument_type)
-<< AL << AANT_ArgumentIdentifier;
-return;
-  }
+bool SemaHLSL::CreateHLSLAttributedResourceType(
+Sema &S, QualType Wrapped, llvm::SmallVector &AttrList,
+QualType &ResType) {
+  assert(AttrList.size() && "expected list of resource attributes");
 
-  IdentifierLoc *Loc = AL.getArgAsIdent(0);
-  StringRef Identifier = Loc->Ident->getName();
-  SourceLocation ArgLoc = Loc->Loc;
+  QualType Contained = QualType();
+  HLSLAttributedResourceType::Attributes ResAttrs = {};
 
-  // Validate.
-  llvm::dxil::ResourceClass RC;
-  if (!HLSLResourceClassAttr::ConvertStrToResourceClass(Identifier, RC)) {
-Diag(ArgLoc, diag::warn_attribute_type_not_supported)
-<< "ResourceClass" << Identifier;
-return;
+  bool hasResourceClass = false;
+  for (auto *Attr : AttrList) {
+if (!Attr)
+  continue;
+switch (Attr->getKind()) {
+case attr::HLSLResourceClass: {
+  llvm::dxil::ResourceClass RC =
+  dyn_cast(Attr)->getResourceClass();
+  if (!hasResourceClass) {
+ResAttrs.ResourceClass = RC;
+hasResourceClass = true;
+  } else if (RC != ResAttrs.ResourceClass) {
+S.Diag(Attr->getLocation(), diag::warn_duplicate_attribute) << Attr;
+return false;
+  }
+  break;
+}
+case attr::HLSLROV:
+  ResAttrs.IsROV = true;
+  break;
+default:
+  llvm_unreachable("unhandled resource attribute type");
+}
   }
 
-  D->addAttr(HLSLResourceClassAttr::Create(getASTContext(), RC, ArgLoc));
+  if (!hasResourceClass) {
+S.Diag(AttrList.back()->getRange().getEnd(),
+   diag::err_missing_resource_class);
+return false;
+  }
+
+  ResType = S.getASTContext().getHLSLAttributedResourceType(Wrapped, Contained,
+ResAttrs);
+  return true;
 }
 
-// Validates HLSL resource type attribute and adds it to the list to be
-// processed into a single HLSLAttributedResourceType later on.
-// Returns false if the attribute is invalid.
+// Validates and creates an HLSL attribute that is applied as type attribute on
+// HLSL resource. The attributes are collected in HLSLResourcesTypeAttrs and at
+// the end of the declaration they are applied to the declaration type by
+// wrapping it in HLSLAttributedResourceType.
 bool SemaHLSL::handleResourceTypeAttr(const ParsedAttr &AL) {
-  // FIXME: placeholder - not yet implemented
+  Attr *A = nullptr;
+
+  // validate number of arguments
+  if (!AL.checkExactlyNumArgs(SemaRef, AL.getMinArgs()))
+return false;
+
+  switch (AL.getKind()) {
+  case ParsedAttr::AT_HLSLResourceClass: {
+if (!AL.isArgIdent(0)) {
+  Diag(AL.getLoc(), diag::err_attribute_argument_type)
+  << AL << AANT_ArgumentIdentifier;
+  return false;
+}
+
+IdentifierLoc *Loc = AL.getArgAsIdent(0);
+StringRef Identifier = Loc->Ident->getName();
+SourceLocation ArgLoc = Loc->Loc;
+
+// Validate resource class value
+llvm::dxil::ResourceClass RC;
+if (!HLSLResourceClassAttr::ConvertStrToResourceClass(Identifier, RC)) {
+  Diag(ArgLoc, diag::warn_attribute_type_not_supported)
+  << "ResourceClass" << Identifier;
+  return false;
+}
+A = HLSLResourceClassAttr::Create(getASTContext(), RC, AL.getLoc());
+break;
+  }
+  case ParsedAttr::AT_HLSLROV:
+A = HLSLROVAttr::Create(getASTContext(), AL.getLoc());
+break;
+  default:
+llvm_unreachable("unhandled HLSL attribute");
+  }
+
+  HLSLResourcesTypeAttrs.emplace_back(A);
   return true;
 }
 
-// Combines all resource type attributes and create HLSLAttributedResourceType.
+// Combines all resource type attributes and creates 
HLSLAttributedResourceType.
 QualType SemaHLSL::ProcessResourceTypeAttributes(QualType CurrentType) {
-  // FIXME: placeholder - not yet implemented
-  return CurrentType;
+  if (!HLSLResourcesTypeAttrs.size())
+return CurrentType;
+
+  QualType QT = CurrentType;
+  if (CreateHLSLAttributedResourceType(SemaRef, CurrentType,
+   HLSLResourcesTypeAttrs, QT)) {
+const HLSLAttributedResourceType *RT =
+dyn_cast(QT.getTypePtr());
+SourceLocation Loc = HLSLResourcesTypeAttrs[0]->getLoc();
+LocsForHLSLAttributedResources.insert(std::pair(RT, Loc));
+  }
+  HLSLResourcesTypeAttrs.clear();
+  return QT;
 }
 
 // Returns source location for the HLSLAttributedResourceType
 SourceLocation
 SemaHLSL::TakeLocForHLSLAttribute(const HLSLAttributedResourceType *RT) {
-  // FIXME: placeholder - not yet implemented
+  auto I = LocsForHLSLAttributedResources.find(RT);
+  if (I != LocsForHLSLAttributedResources.end()) {
+SourceLocation Loc = I->second;
+LocsForHLSL

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

@@ -1,32 +1,32 @@
 // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -ast-dump -o 
- %s | FileCheck %s
 
-
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  SRV
-struct Eg1 {
-  [[hlsl::resource_class(SRV)]] int i;  
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}} {{.*}} struct MyBuffer definition
+// CHECK: FieldDecl 0x{{[0-9a-f]+}}  col:51 h 
'__hlsl_resource_t {{\[\[}}hlsl::resource_class(UAV)]]':'__hlsl_resource_t'
+struct MyBuffer {
+  __hlsl_resource_t [[hlsl::resource_class(UAV)]] h;
 };
 
-Eg1 e1;
-
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:13:8 
referenced struct Eg2 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  UAV
-struct Eg2 {
-  [[hlsl::resource_class(UAV)]] int i;
-};
-Eg2 e2;
+// CHECK: VarDecl 0x{{[0-9a-f]+}}  col:49 res 
'__hlsl_resource_t {{\[\[}}hlsl::resource_class(SRV)]]':'__hlsl_resource_t'
+__hlsl_resource_t [[hlsl::resource_class(SRV)]] res;
 
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:20:8 
referenced struct Eg3 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  CBuffer
-struct Eg3 {
-  [[hlsl::resource_class(CBuffer)]] int i;
-}; 
-Eg3 e3;
+// CHECK: FunctionDecl 0x{{[0-9a-f]+}}  line:14:6 f 
'void ()
+// CHECK: VarDecl 0x{{[0-9a-f]+}}  col:55 r '__hlsl_resource_t 
{{\[\[}}hlsl::resource_class(Sampler)]]':'__hlsl_resource_t'
+void f() {
+  __hlsl_resource_t [[hlsl::resource_class(Sampler)]] r;
+}
 
-// CHECK: -CXXRecordDecl 0x{{[0-9a-f]+}}  line:27:8 
referenced struct Eg4 definition
-// CHECK: -HLSLResourceClassAttr 0x{{[0-9a-f]+}}  Sampler
-struct Eg4 {
-  [[hlsl::resource_class(Sampler)]] int i;
+// CHECK: ClassTemplateDecl 0x{{[0-9a-f]+}}  line:23:29 
MyBuffer2
+// CHECK: TemplateTypeParmDecl 0x{{[0-9a-f]+}}  col:19 
referenced typename depth 0 index 0 T
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}}  line:23:29 struct 
MyBuffer2 definition
+// CHECK: CXXRecordDecl 0x{{[0-9a-f]+}}  col:29 implicit 
struct MyBuffer2
+// CHECK: FieldDecl 0x{{[0-9a-f]+}}  col:35 h 'T 
{{\[\[}}hlsl::resource_class(UAV)]]':'T'
+template struct MyBuffer2 {
+  T [[hlsl::resource_class(UAV)]] h;

damyanp wrote:

There's multiple tests below (that are modifications of existing ones) that are 
still using this field with the element type rather than a handle type, but I 
won't put comments on all of them.

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

[clang] [HLSL] Apply resource attributes to the resource type rather than the handle member (PR #107160)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Remove variables that are used only in assert (PR #107299)

[Damyan Pepper via cfe-commits]

@@ -834,17 +834,10 @@ static void ValidateMultipleRegisterAnnotations(Sema &S, 
Decl *TheDecl,
 static void DiagnoseHLSLRegisterAttribute(Sema &S, SourceLocation &ArgLoc,
   Decl *TheDecl, RegisterType regType) 
{
 
-  // Samplers, UAVs, and SRVs are VarDecl types
-  VarDecl *TheVarDecl = dyn_cast(TheDecl);
-  // Cbuffers and Tbuffers are HLSLBufferDecl types
-  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(TheDecl);
-
   // exactly one of these two types should be set
-  assert(((TheVarDecl && !CBufferOrTBuffer) ||
-  (!TheVarDecl && CBufferOrTBuffer)) &&
+  assert(((isa(TheDecl) && !isa(TheDecl)) ||
+  (!isa(TheDecl) && isa(TheDecl))) &&
  "either TheVarDecl or CBufferOrTBuffer should be set");

damyanp wrote:

The text that goes with this assert doesn't really make sense any more.

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

[clang] [HLSL] Remove variables that are used only in assert (PR #107299)

[Damyan Pepper via cfe-commits]

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


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

[clang] [DirectX] Add DirectXTargetCodeGenInfo (PR #104856)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.

It would be good to have some test coverage to go along with this.

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

[clang] [HLSL] Implement support for HLSL intrinsic - select (PR #107129)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp commented:

LGTM - would be good to get approval from @farzonl before completing.

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

[clang] [HLSL] set alwaysinline on HLSL functions (PR #106588)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,114 @@
+// RUN: %clang_cc1 -x hlsl -triple  dxil-pc-shadermodel6.3-library %s 
-emit-llvm -disable-llvm-passes -o - | FileCheck %s 
--check-prefixes=CHECK,NOINLINE
+// RUN: %clang_cc1 -x hlsl -triple  dxil-pc-shadermodel6.3-library %s 
-emit-llvm -O0 -o - | FileCheck %s --check-prefixes=CHECK,INLINE
+// RUN: %clang_cc1 -x hlsl -triple  dxil-pc-shadermodel6.0-compute %s 
-emit-llvm -disable-llvm-passes -o - | FileCheck %s 
--check-prefixes=CHECK,NOINLINE
+// RUN: %clang_cc1 -x hlsl -triple  dxil-pc-shadermodel6.0-compute %s 
-emit-llvm -O0 -o - | FileCheck %s --check-prefixes=CHECK,INLINE
+
+// Tests that user functions will always be inlined.
+// This includes exported functions and mangled entry point implementation 
functions.
+// The unmangled entry functions must not be alwaysinlined.
+
+#define MAX 100
+
+float nums[MAX];
+
+// Verify that all functions have the alwaysinline attribute
+// CHECK: Function Attrs: alwaysinline
+// CHECK: define void @"?swap@@YAXY0GE@III@Z"(ptr noundef byval([100 x i32]) 
align 4 %Buf, i32 noundef %ix1, i32 noundef %ix2) [[IntAttr:\#[0-9]+]]

damyanp wrote:

(probably a learning opportunity for me:)

Wondering why the define is still expected here. I would have expected it to 
not appear because it got inlined. 

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

[clang] [HLSL] set alwaysinline on HLSL functions (PR #106588)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -std=hlsl202x 
-emit-llvm -o - -disable-llvm-passes %s | FileCheck %s 
--check-prefixes=CHECK,NOINLINE
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -std=hlsl202x 
-emit-llvm -o - -disable-llvm-passes %s | FileCheck %s 
--check-prefixes=CHECK,NOINLINE
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -std=hlsl202x 
-emit-llvm -o - -O0 %s | FileCheck %s --check-prefixes=CHECK,INLINE
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -std=hlsl202x 
-emit-llvm -o - -O0 %s | FileCheck %s --check-prefixes=CHECK,INLINE
+
+// Tests that implicit contstructor calls for user classes will always be 
inlined.

damyanp wrote:

typo

```suggestion
// Tests that implicit constructor calls for user classes will always be 
inlined.
```

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

[clang] [HLSL] set alwaysinline on HLSL functions (PR #106588)

[Damyan Pepper via cfe-commits]

@@ -2474,7 +2474,9 @@ void 
CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
 // If we don't have a declaration to control inlining, the function isn't
 // explicitly marked as alwaysinline for semantic reasons, and inlining is
 // disabled, mark the function as noinline.
+// HLSL functions must be always inlined
 if (!F->hasFnAttribute(llvm::Attribute::AlwaysInline) &&
+!getLangOpts().HLSL &&

damyanp wrote:

A bit lower down there's some similar checks that seem to involve 
`AlwaysInline` and `OnlyAlwaysInlining` (around line 2536).  Does this also 
need to be updated for HLSL mode?

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

[clang] [HLSL] set alwaysinline on HLSL functions (PR #106588)

[Damyan Pepper via cfe-commits]

@@ -1239,9 +1239,9 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
QualType RetTy,
   if (getLangOpts().OpenMP && CurCodeDecl)
 CGM.getOpenMPRuntime().emitFunctionProlog(*this, CurCodeDecl);
 
-  if (FD && getLangOpts().HLSL) {
+  if (getLangOpts().HLSL) {
 // Handle emitting HLSL entry functions.
-if (FD->hasAttr()) {
+if (FD && FD->hasAttr()) {
   CGM.getHLSLRuntime().emitEntryFunction(FD, Fn);
 }
 CGM.getHLSLRuntime().setHLSLFunctionAttributes(FD, Fn);

damyanp wrote:

Maybe not for this change, but a bit of me is wondering if the two 
CGHLSLRuntime functions emitEntryFunction and setHLSLFunctionAttributes should 
be somewhat combined so that we end up with something like:

```c++
if (getLangOpts().HLSL)
CGM.getHLSLRuntime().emitFunctionProlog(FD, Fn);
```

Similar to how this is encapsulated for OpenMP above.  That way we get more of 
the HLSL-specific stuff in CGHLSLRuntime.cpp.

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

[clang] [llvm] [DirectX] Add DirectXTargetCodeGenInfo (PR #104856)

[Damyan Pepper via cfe-commits]

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

[clang] [llvm] [DirectX] Add DirectXTargetCodeGenInfo (PR #104856)

[Damyan Pepper via cfe-commits]

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

I've a few questions here, but otherwise LGTMy non-expert eyes.  Would be good 
to get a review from @bogner before completing.

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

[clang] [llvm] [DirectX] Add DirectXTargetCodeGenInfo (PR #104856)

[Damyan Pepper via cfe-commits]

@@ -879,6 +879,10 @@ static TargetTypeInfo getTargetTypeInfo(const 
TargetExtType *Ty) {
 ScalableVectorType::get(Type::getInt8Ty(C), TotalNumElts));
   }
 
+  // DirectX intangible types
+  if (Name.starts_with("dx."))
+return TargetTypeInfo(PointerType::get(C, 0), TargetExtType::CanBeGlobal);

damyanp wrote:

What does the `CanBeGlobal` flag do? I notice that `spirv.` also gets 
`HasZeroInit`. Are we sure we don't need that here as well?

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

[clang] [llvm] [DirectX] Add DirectXTargetCodeGenInfo (PR #104856)

[Damyan Pepper via cfe-commits]

@@ -879,6 +879,10 @@ static TargetTypeInfo getTargetTypeInfo(const 
TargetExtType *Ty) {
 ScalableVectorType::get(Type::getInt8Ty(C), TotalNumElts));
   }
 
+  // DirectX intangible types
+  if (Name.starts_with("dx."))

damyanp wrote:

I'm surprised that we do a name lookup here, rather than key off some 
attributes, but I also see that this is how it is done for some spirv and riscv 
types.

Are we definitely ok with burning all the `dx.` prefixed names for this?



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

[clang] [HLSL] set alwaysinline on HLSL functions (PR #106588)

[Damyan Pepper via cfe-commits]

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

LGTM, but would be good to get a review from someone more knowledgeable in the 
area than I am.

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

[clang] [HLSL] Add `[[hlsl::row_access]]` attribute (PR #107954)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.

There's been some discussion about the design for this offline that should be 
resolved before this PR is completed.

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

[clang] [llvm] [HLSL] Mark exported functions with "hlsl.export" attribute (PR #102275)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Split out the ROV attribute from the resource attribute, make it a new spellable attribute. (PR #102414)

[Damyan Pepper via cfe-commits]

https://github.com/damyanp requested changes to this pull request.


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

[clang] [HLSL] Split out the ROV attribute from the resource attribute, make it a new spellable attribute. (PR #102414)

[Damyan Pepper via cfe-commits]

@@ -116,12 +116,15 @@ struct BuiltinTypeDeclBuilder {
 QualType(TTD->getTypeForDecl(), 0));
 }
 // add handle member
-llvm::SmallVector Attrs;
 Attr *ResourceClassAttr =
 HLSLResourceClassAttr::CreateImplicit(Record->getASTContext(), RC);
 Attr *ResourceAttr =
-HLSLResourceAttr::CreateImplicit(Record->getASTContext(), RK, IsROV);
+HLSLResourceAttr::CreateImplicit(Record->getASTContext(), RK);
 addMemberVariable("h", Ty, {ResourceClassAttr, ResourceAttr}, Access);
+if (IsROV)

damyanp wrote:

It would be nice if we could find a way to be more consistent with how the 
other attributes are added to the field, and so only follow a single pattern 
for adding them.

What if we arranged it so we could write:

```c++
Attr *ResourceClassAttr =
HLSLResourceClassAttr::CreateImplicit(Record->getASTContext(), RC);
Attr *ResourceAttr =
HLSLResourceAttr::CreateImplicit(Record->getASTContext(), RK);
Attr *ROVAttr = IsRov ? HLSLROVAttr::CreateImplicit(Record->getASTContents()) : 
nullptr;
addMemberVariable("h", Ty, {ResourceClassAttr, ResourceAttr, ROVAttr}, Access);
```

There may be other ways to slice it - my main request here is that we end up 
with a consistent way of doing this.

Remember `addMemberVariable` _only_ exists in order for us to create this `h` 
member, so we can adapt it to work well for this purpose.

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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

damyanp wrote:

> HLSL tends to rely pretty aggressively on scalarization occuring in the 
> complier, which allows for some relaxed language behaviors when types are 
> fully sclarized to equivalent scalar representations.

Some typos:

* occuring --> occurring
* complier --> compiler
* sclarized --> scalarized

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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

@@ -1142,3 +1142,85 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
   }
   return false;
 }
+
+static void BuildFlattenedTypeList(QualType BaseTy,
+   llvm::SmallVectorImpl &List) {
+  llvm::SmallVector WorkList;
+  WorkList.push_back(BaseTy);
+  while (!WorkList.empty()) {
+QualType T = WorkList.pop_back_val();
+T = T.getCanonicalType().getUnqualifiedType();
+assert(!isa(T) && "Matrix types not yet supported in HLSL");
+if (const auto *AT = dyn_cast(T)) {
+  llvm::SmallVector ElementFields;
+  // Generally I've avoided recursion in this algorithm, but arrays of
+  // structs could be time-consuming to flatten and churn through on the
+  // work list. Hopefully nesting arrays of structs containing arrays
+  // of structs too many levels deep is unlikely.
+  BuildFlattenedTypeList(AT->getElementType(), ElementFields);
+  // Repeat the element's field list n times.
+  for (uint64_t Ct = 0; Ct < AT->getZExtSize(); ++Ct)
+List.insert(List.end(), ElementFields.begin(), ElementFields.end());
+  continue;
+}
+// Vectors can only have element types that are builtin types, so this can
+// add directly to the list instead of to the WorkList.
+if (const auto *VT = dyn_cast(T)) {
+  List.insert(List.end(), VT->getNumElements(), VT->getElementType());
+  continue;
+}
+if (const auto *RT = dyn_cast(T)) {
+  const RecordDecl *RD = RT->getDecl();
+  if (RD->isUnion()) {

damyanp wrote:

Can vector types be put inside unions, or are unions guaranteed to be scalar? 
Does this deserve a comment explaining it in the same way that there's one for 
vectors?

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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

@@ -1142,3 +1142,85 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
   }
   return false;
 }
+
+static void BuildFlattenedTypeList(QualType BaseTy,
+   llvm::SmallVectorImpl &List) {
+  llvm::SmallVector WorkList;
+  WorkList.push_back(BaseTy);
+  while (!WorkList.empty()) {
+QualType T = WorkList.pop_back_val();
+T = T.getCanonicalType().getUnqualifiedType();
+assert(!isa(T) && "Matrix types not yet supported in HLSL");
+if (const auto *AT = dyn_cast(T)) {
+  llvm::SmallVector ElementFields;
+  // Generally I've avoided recursion in this algorithm, but arrays of
+  // structs could be time-consuming to flatten and churn through on the
+  // work list. Hopefully nesting arrays of structs containing arrays
+  // of structs too many levels deep is unlikely.
+  BuildFlattenedTypeList(AT->getElementType(), ElementFields);
+  // Repeat the element's field list n times.
+  for (uint64_t Ct = 0; Ct < AT->getZExtSize(); ++Ct)
+List.insert(List.end(), ElementFields.begin(), ElementFields.end());
+  continue;
+}
+// Vectors can only have element types that are builtin types, so this can
+// add directly to the list instead of to the WorkList.
+if (const auto *VT = dyn_cast(T)) {
+  List.insert(List.end(), VT->getNumElements(), VT->getElementType());
+  continue;
+}
+if (const auto *RT = dyn_cast(T)) {
+  const RecordDecl *RD = RT->getDecl();
+  if (RD->isUnion()) {
+List.push_back(T);
+continue;
+  }
+  const CXXRecordDecl *CXXD = dyn_cast(RD);
+
+  llvm::SmallVector FieldTypes;
+  if (CXXD && CXXD->isStandardLayout())
+RD = CXXD->getStandardLayoutBaseWithFields();
+
+  for (const auto *FD : RD->fields())
+FieldTypes.push_back(FD->getType());
+  // Reverse the newly added sub-range.
+  std::reverse(FieldTypes.begin(), FieldTypes.end());

damyanp wrote:

Is it obvious to someone with more domain knowledge why this has to be reversed?

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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,132 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.6-library 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.6-library 
-finclude-default-header -fnative-half-type -verify %s
+// expected-no-diagnostics
+
+// Case 1: How many ways can I come up with to represent three float values?
+struct ThreeFloats1 {
+  float X, Y, Z;
+};
+
+struct ThreeFloats2 {
+  float X[3];
+};
+
+struct ThreeFloats3 {
+  float3 V;
+};
+
+struct ThreeFloats4 {
+  float2 V;
+  float F;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(float3, float[3]), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats1), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats2), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats3), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats4), "");
+
+// Case 2: structs and base classes and arrays, oh my!
+struct Dog {
+  int Leg[4];
+  bool Tail;
+  float Fur;
+};
+
+struct Shiba {
+  int4 StubbyLegs;
+  bool CurlyTail;
+  struct Coating {
+float Fur;
+  } F;
+};
+
+struct FourLegged {
+  int FR, FL, BR, BL;
+};
+
+struct Doggo : FourLegged {
+  bool WaggyBit;
+  float Fuzz;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Dog, Shiba), "");
+_Static_assert(__is_scalarized_layout_compatible(Dog, Doggo), "");
+
+// Case 3: Arrays of structs inside structs
+
+struct Cat {
+  struct Leg {
+int L;
+  } Legs[4];
+  struct Other {
+bool Tail;
+float Furs;
+  } Bits;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Dog, Cat), "");
+
+// case 4: Arrays of structs inside arrays of structs.
+struct Pets {
+  Dog Puppers[6];
+  Cat Kitties[4];
+};
+
+struct Animals {
+  Dog Puppers[2];
+  Cat Kitties[8];
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Pets, Animals), "");
+
+// Case 5: Turtles all the way down...
+
+typedef int Turtle;
+
+enum Ninja : Turtle {
+  Leonardo,
+  Donatello,
+  Michelangelo,
+  Raphael,
+};
+
+enum NotNinja : Turtle {
+  Fred,
+  Mikey,
+};
+
+enum Mammals : uint {
+  Dog,
+  Cat,
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Ninja, NotNinja), "");
+_Static_assert(!__is_scalarized_layout_compatible(Ninja, Mammals), "");
+
+// Case 6: Some basic types.
+_Static_assert(__is_scalarized_layout_compatible(int, int32_t), "");
+_Static_assert(__is_scalarized_layout_compatible(uint, uint32_t), "");
+_Static_assert(!__is_scalarized_layout_compatible(int, uint), "");
+_Static_assert(!__is_scalarized_layout_compatible(int, float), "");
+
+// Even though half and float may be the same size we don't want them to be
+// layout compatible since they are different types.
+_Static_assert(!__is_scalarized_layout_compatible(half, float), "");
+
+// Case 6: Empty classes... because they're fun.
+
+struct NotEmpty { int X; };
+struct Empty {};
+struct AlsoEmpty {};
+
+struct DerivedEmpty : Empty {};
+
+struct DerivedNotEmpty : Empty { int X; };
+struct DerivedEmptyNotEmptyBase : NotEmpty {};
+
+_Static_assert(__is_scalarized_layout_compatible(Empty, AlsoEmpty), "");
+_Static_assert(__is_scalarized_layout_compatible(Empty, DerivedEmpty), "");
+
+_Static_assert(__is_scalarized_layout_compatible(NotEmpty, DerivedNotEmpty), 
"");
+_Static_assert(__is_scalarized_layout_compatible(NotEmpty, 
DerivedEmptyNotEmptyBase), "");

damyanp wrote:

test case for unions?

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

[clang] [HLSL] Add __is_scalarized_layout_compatible (PR #102227)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,132 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.6-library 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.6-library 
-finclude-default-header -fnative-half-type -verify %s
+// expected-no-diagnostics
+
+// Case 1: How many ways can I come up with to represent three float values?
+struct ThreeFloats1 {
+  float X, Y, Z;
+};
+
+struct ThreeFloats2 {
+  float X[3];
+};
+
+struct ThreeFloats3 {
+  float3 V;
+};
+
+struct ThreeFloats4 {
+  float2 V;
+  float F;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(float3, float[3]), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats1), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats2), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats3), "");
+_Static_assert(__is_scalarized_layout_compatible(float3, ThreeFloats4), "");
+
+// Case 2: structs and base classes and arrays, oh my!
+struct Dog {
+  int Leg[4];
+  bool Tail;
+  float Fur;
+};
+
+struct Shiba {
+  int4 StubbyLegs;
+  bool CurlyTail;
+  struct Coating {
+float Fur;
+  } F;
+};
+
+struct FourLegged {
+  int FR, FL, BR, BL;
+};
+
+struct Doggo : FourLegged {
+  bool WaggyBit;
+  float Fuzz;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Dog, Shiba), "");
+_Static_assert(__is_scalarized_layout_compatible(Dog, Doggo), "");
+
+// Case 3: Arrays of structs inside structs
+
+struct Cat {
+  struct Leg {
+int L;
+  } Legs[4];
+  struct Other {
+bool Tail;
+float Furs;
+  } Bits;
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Dog, Cat), "");
+
+// case 4: Arrays of structs inside arrays of structs.
+struct Pets {
+  Dog Puppers[6];
+  Cat Kitties[4];
+};
+
+struct Animals {
+  Dog Puppers[2];
+  Cat Kitties[8];
+};
+
+_Static_assert(__is_scalarized_layout_compatible(Pets, Animals), "");
+
+// Case 5: Turtles all the way down...
+
+typedef int Turtle;
+
+enum Ninja : Turtle {
+  Leonardo,
+  Donatello,
+  Michelangelo,
+  Raphael,
+};
+
+enum NotNinja : Turtle {
+  Fred,
+  Mikey,
+};
+
+enum Mammals : uint {

damyanp wrote:

No Rat or Splinter??

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

[clang] [HLSL] Split out the ROV attribute from the resource attribute, make it a new spellable attribute. (PR #102414)

[Damyan Pepper via cfe-commits]

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


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

[clang] Implement resource binding type prefix mismatch diagnostic infrastructure (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -459,7 +467,506 @@ void SemaHLSL::handleResourceClassAttr(Decl *D, const 
ParsedAttr &AL) {
   D->addAttr(HLSLResourceClassAttr::Create(getASTContext(), RC, ArgLoc));
 }
 
-void SemaHLSL::handleResourceBindingAttr(Decl *D, const ParsedAttr &AL) {
+struct RegisterBindingFlags {
+  bool Resource = false;
+  bool UDT = false;
+  bool Other = false;
+  bool Basic = false;
+
+  bool SRV = false;
+  bool UAV = false;
+  bool CBV = false;
+  bool Sampler = false;
+
+  bool ContainsNumeric = false;
+  bool DefaultGlobals = false;
+};
+
+bool isDeclaredWithinCOrTBuffer(const Decl *TheDecl) {

damyanp wrote:

This may apply to the other functions added to this file that are only intended 
to be called from using this TU.

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

[clang] Implement resource binding type prefix mismatch diagnostic infrastructure (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,103 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - 
-fsyntax-only %s -verify
+
+// TODO: Implement "Buffer", we use a substitute UDT
+// to test the 't' binding type for this test.
+
+template
+struct [[hlsl::resource_class(SRV)]] Buffer {

damyanp wrote:

I don't understand why these are in the UDT section.  The cases where the 
resource_class attribute is present is a different case than a UDT.

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

[clang] Implement resource binding type prefix mismatch diagnostic infrastructure (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -38,6 +38,14 @@ Decl *SemaHLSL::ActOnStartBuffer(Scope *BufferScope, bool 
CBuffer,
   HLSLBufferDecl *Result = HLSLBufferDecl::Create(
   getASTContext(), LexicalParent, CBuffer, KwLoc, Ident, IdentLoc, LBrace);
 
+  auto RC = CBuffer ? llvm::hlsl::ResourceClass::CBuffer
+: llvm::hlsl::ResourceClass::SRV;
+  auto RK = CBuffer ? llvm::hlsl::ResourceKind::CBuffer

damyanp wrote:

aso tbuffer's are SRVs!  I remember trying to figure that out before 
reading the docs and getting very confused.  I don't quite understand that 
tbuffers are for.

One nit here: it took me a moment to remember that this code treats "not 
cbuffer" as "tbuffer". Maybe a comment here noting that would help?

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