[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] [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][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][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] 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] [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]

@@ -0,0 +1,562 @@
+
+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 main entry 
+point):
+
+.. code-block::
+
+#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(MyRS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+…
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root signature could also used in form of StateObject like this:
+
+.. code-block::
+
+  GlobalRootSignature MyGlobalRootSignature =
+  {
+  "DescriptorTable(UAV(u0))," // Output texture
+  "SRV(t0),"  // Acceleration structure
+  "CBV(b0),"  // Scene constants
+  "DescriptorTable(SRV(t1, numDescriptors = 2))"  // Static index and 
vertex buffers.
+  };
+
+  LocalRootSignature MyLocalRootSignature = 
+  {
+  "RootConstants(num32BitConstants = 4, b1)"  // Cube constants 
+  };
+
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescript

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

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,562 @@
+
+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 main entry 
+point):
+
+.. code-block::
+
+#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(MyRS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+…
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root signature could also used in form of StateObject like this:
+
+.. code-block::
+
+  GlobalRootSignature MyGlobalRootSignature =
+  {
+  "DescriptorTable(UAV(u0))," // Output texture
+  "SRV(t0),"  // Acceleration structure
+  "CBV(b0),"  // Scene constants
+  "DescriptorTable(SRV(t1, numDescriptors = 2))"  // Static index and 
vertex buffers.
+  };
+
+  LocalRootSignature MyLocalRootSignature = 
+  {
+  "RootConstants(num32BitConstants = 4, b1)"  // Cube constants 
+  };
+
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescript

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

[Damyan Pepper via cfe-commits]

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

There are some open comments that don't seem like they've been resolved yet 
(along with a couple of typos I've pointed out).

With 85 comments this PR is become quite hard to follow.  I wonder if we're at 
a point now where it's either good enough to go in and have issues filed 
against it, or if we need to abandon this one and start a fresh one?

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 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] [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] 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] [HLSL] Shore up floating point conversions (PR #90222)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,229 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -fnative-half-type 
-finclude-default-header -Wconversion -verify -o - %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -fnative-half-type 
-finclude-default-header -ast-dump %s | FileCheck %s
+
+// This test verifies floating point type implicit conversion ranks for 
overload
+// resolution. In HLSL the built-in type ranks are half < float < double. This
+// applies to both scalar and vector types.
+
+// HLSL allows implicit truncation fo types, so it differentiates between
+// promotions (converting to larger types) and conversions (converting to
+// smaller types). Promotions are preferred over conversions. Promotions prefer
+// promoting to the next lowest type in the ranking order. Conversions prefer
+// converting to the next highest type in the ranking order.
+
+void HalfFloatDouble(double D);
+void HalfFloatDouble(float F);
+void HalfFloatDouble(half H);
+
+// CHECK: FunctionDecl {{.*}} used HalfFloatDouble 'void (double)'

damyanp wrote:

Just a question: are these `CHECK: FunctionDecl`s here as a sanity check, or 
are they validating something about this change or have some functional purpose 
to making the test work?

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

[clang] [HLSL] Shore up floating point conversions (PR #90222)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

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

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an

damyanp wrote:

what is a "binding space"?

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

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an
+   index into a dynamic resource heap.
+
+   In LLVM we represent binding information in the arguments of the
+   :ref:`handle creation intrinsics `. When generating
+   DXIL we transform these calls to metadata, ``dx.op.createHandle``,
+   ``dx.op.createHandleFromBinding``, ``dx.op.createHandleFromHeap``, and
+   ``dx.op.createHandleForLib`` as needed.
+
+`Type information`
+   The type of data that's accessible via the resource. For buffers and
+   textures this can be a simple type like ``float`` or ``float4``, a struct,
+   or raw bytes. For constant buffers this is just a size. For samplers this is
+   the kind of sampler.
+
+   In LLVM we embed this information as a parameter on the ``target()`` type of
+   the resource. See :ref:`dxil-resources-types-of-resource`.
+
+`Resource kind information`
+   The kind of resource. In HLSL we have things like ``ByteAddressBuffer``,
+   ``RWTexture2D``, and ``RasterizerOrderedStructuredBuffer``. These map to a
+   set of DXIL kinds like ``RawBuffer`` and ``Texture2D`` with fields for
+   certain properties such as ``IsUAV`` and ``IsROV``.
+
+   In LLVM we represent this in the ``target()`` type. We omit information
+   that's deriveable from the type information, but we do have fields to encode
+   ``IsWriteable``, ``IsROV``, and ``SampleCount`` when needed.
+
+.. note:: TODO: There are two fields in the DXIL metadata that are not
+   represented as part of the target type: ``IsGloballyCoherent`` and
+   ``HasCounter``.
+
+   Since these are derived from analysis, storing them on the type would mean
+   we need to change the type during the compiler pipeline. That just isn't
+   practical. It isn't entirely clear to me that we need to serialize this info
+   into the IR during the compiler pipeline anyway - we can probably get away
+   with an analysis pass that can calculate the information when we need it.
+
+   If analysis is insufficient we'll need something akin to ``annotateHandle``
+   (but limited to these two properties) or to encode these in the handle
+   creation.
+
+.. _dxil-resources-types-of-resource:
+
+Types of Resource
+=
+
+We define a set of ``TargetExtTypes`` that is similar to the HLSL
+representations for the various resources, albeit with a few things
+parameterized. This is different than DXIL, as simplifying the types to
+something like "dx.srv" and "dx.uav" types would mean the operations on these
+types would have to be overly generic.
+
+Samplers
+
+
+.. code-block:: llvm
+
+   target("dx.Sampler", SamplerType)
+
+The "dx.Sampler" type is used to represent sampler state. The sampler type is
+an enum value from the DXIL ABI, and these appear in sampling operations as

damyanp wrote:

> The sample type is an enum value from the DXIL ABI

Do we want to tie this so closely to the DXIL ABI?  Would an extra level of 
indirection here allow LLVM and DXIL to evolve independently?

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

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an
+   index into a dynamic resource heap.
+
+   In LLVM we represent binding information in the arguments of the
+   :ref:`handle creation intrinsics `. When generating
+   DXIL we transform these calls to metadata, ``dx.op.createHandle``,
+   ``dx.op.createHandleFromBinding``, ``dx.op.createHandleFromHeap``, and
+   ``dx.op.createHandleForLib`` as needed.
+
+`Type information`
+   The type of data that's accessible via the resource. For buffers and
+   textures this can be a simple type like ``float`` or ``float4``, a struct,
+   or raw bytes. For constant buffers this is just a size. For samplers this is
+   the kind of sampler.
+
+   In LLVM we embed this information as a parameter on the ``target()`` type of
+   the resource. See :ref:`dxil-resources-types-of-resource`.
+
+`Resource kind information`
+   The kind of resource. In HLSL we have things like ``ByteAddressBuffer``,
+   ``RWTexture2D``, and ``RasterizerOrderedStructuredBuffer``. These map to a
+   set of DXIL kinds like ``RawBuffer`` and ``Texture2D`` with fields for
+   certain properties such as ``IsUAV`` and ``IsROV``.
+
+   In LLVM we represent this in the ``target()`` type. We omit information
+   that's deriveable from the type information, but we do have fields to encode
+   ``IsWriteable``, ``IsROV``, and ``SampleCount`` when needed.
+
+.. note:: TODO: There are two fields in the DXIL metadata that are not
+   represented as part of the target type: ``IsGloballyCoherent`` and
+   ``HasCounter``.
+
+   Since these are derived from analysis, storing them on the type would mean
+   we need to change the type during the compiler pipeline. That just isn't
+   practical. It isn't entirely clear to me that we need to serialize this info
+   into the IR during the compiler pipeline anyway - we can probably get away
+   with an analysis pass that can calculate the information when we need it.
+
+   If analysis is insufficient we'll need something akin to ``annotateHandle``
+   (but limited to these two properties) or to encode these in the handle
+   creation.
+
+.. _dxil-resources-types-of-resource:
+
+Types of Resource
+=
+
+We define a set of ``TargetExtTypes`` that is similar to the HLSL
+representations for the various resources, albeit with a few things
+parameterized. This is different than DXIL, as simplifying the types to
+something like "dx.srv" and "dx.uav" types would mean the operations on these
+types would have to be overly generic.
+
+Samplers
+
+
+.. code-block:: llvm
+
+   target("dx.Sampler", SamplerType)
+
+The "dx.Sampler" type is used to represent sampler state. The sampler type is
+an enum value from the DXIL ABI, and these appear in sampling operations as
+well as LOD calculations and texture gather.
+
+Constant Buffers
+
+
+.. code-block:: llvm
+
+   target("dx.CBuffer", BufferSize)
+
+The "dx.CBuffer" type is a constant buffer of the given size. Note that despite
+the name this is distinct from the buffer types, and can only be read using the
+"dx.CBufferLoad" and "dx.CBufferLoadLegacy" operations.

damyanp wrote:

> "dx.CBufferLoad"

Didn't we just remove support for this from DXC? (I may be misunderstanding 
things)

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

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an
+   index into a dynamic resource heap.
+
+   In LLVM we represent binding information in the arguments of the
+   :ref:`handle creation intrinsics `. When generating
+   DXIL we transform these calls to metadata, ``dx.op.createHandle``,
+   ``dx.op.createHandleFromBinding``, ``dx.op.createHandleFromHeap``, and
+   ``dx.op.createHandleForLib`` as needed.
+
+`Type information`
+   The type of data that's accessible via the resource. For buffers and
+   textures this can be a simple type like ``float`` or ``float4``, a struct,
+   or raw bytes. For constant buffers this is just a size. For samplers this is
+   the kind of sampler.
+
+   In LLVM we embed this information as a parameter on the ``target()`` type of
+   the resource. See :ref:`dxil-resources-types-of-resource`.
+
+`Resource kind information`
+   The kind of resource. In HLSL we have things like ``ByteAddressBuffer``,
+   ``RWTexture2D``, and ``RasterizerOrderedStructuredBuffer``. These map to a
+   set of DXIL kinds like ``RawBuffer`` and ``Texture2D`` with fields for
+   certain properties such as ``IsUAV`` and ``IsROV``.
+
+   In LLVM we represent this in the ``target()`` type. We omit information
+   that's deriveable from the type information, but we do have fields to encode
+   ``IsWriteable``, ``IsROV``, and ``SampleCount`` when needed.
+
+.. note:: TODO: There are two fields in the DXIL metadata that are not
+   represented as part of the target type: ``IsGloballyCoherent`` and
+   ``HasCounter``.
+
+   Since these are derived from analysis, storing them on the type would mean
+   we need to change the type during the compiler pipeline. That just isn't
+   practical. It isn't entirely clear to me that we need to serialize this info
+   into the IR during the compiler pipeline anyway - we can probably get away
+   with an analysis pass that can calculate the information when we need it.
+
+   If analysis is insufficient we'll need something akin to ``annotateHandle``
+   (but limited to these two properties) or to encode these in the handle
+   creation.
+
+.. _dxil-resources-types-of-resource:
+
+Types of Resource
+=
+
+We define a set of ``TargetExtTypes`` that is similar to the HLSL
+representations for the various resources, albeit with a few things
+parameterized. This is different than DXIL, as simplifying the types to
+something like "dx.srv" and "dx.uav" types would mean the operations on these
+types would have to be overly generic.
+
+Samplers
+
+
+.. code-block:: llvm
+
+   target("dx.Sampler", SamplerType)
+
+The "dx.Sampler" type is used to represent sampler state. The sampler type is
+an enum value from the DXIL ABI, and these appear in sampling operations as
+well as LOD calculations and texture gather.
+
+Constant Buffers
+
+
+.. code-block:: llvm
+
+   target("dx.CBuffer", BufferSize)
+
+The "dx.CBuffer" type is a constant buffer of the given size. Note that despite
+the name this is distinct from the buffer types, and can only be read using the
+"dx.CBufferLoad" and "dx.CBufferLoadLegacy" operations.
+
+Buffers
+---
+
+.. code-block:: llvm
+
+   target("dx.Buffer", ElementType, IsWriteable, IsROV)
+
+There is only one buffer type. This can represent both UAVs and SRVs via the
+``IsWriteable`` field. Since the type that's encoded is an llvm type, it
+handles both ``Buffer`` and ``StructuredBuffer`` uniformly. For ``RawBuffer``,
+the type is ``i8``, which is unambiguous since ``char

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an
+   index into a dynamic resource heap.
+
+   In LLVM we represent binding information in the arguments of the
+   :ref:`handle creation intrinsics `. When generating
+   DXIL we transform these calls to metadata, ``dx.op.createHandle``,
+   ``dx.op.createHandleFromBinding``, ``dx.op.createHandleFromHeap``, and
+   ``dx.op.createHandleForLib`` as needed.
+
+`Type information`
+   The type of data that's accessible via the resource. For buffers and
+   textures this can be a simple type like ``float`` or ``float4``, a struct,
+   or raw bytes. For constant buffers this is just a size. For samplers this is
+   the kind of sampler.
+
+   In LLVM we embed this information as a parameter on the ``target()`` type of
+   the resource. See :ref:`dxil-resources-types-of-resource`.
+
+`Resource kind information`
+   The kind of resource. In HLSL we have things like ``ByteAddressBuffer``,
+   ``RWTexture2D``, and ``RasterizerOrderedStructuredBuffer``. These map to a
+   set of DXIL kinds like ``RawBuffer`` and ``Texture2D`` with fields for
+   certain properties such as ``IsUAV`` and ``IsROV``.
+
+   In LLVM we represent this in the ``target()`` type. We omit information
+   that's deriveable from the type information, but we do have fields to encode
+   ``IsWriteable``, ``IsROV``, and ``SampleCount`` when needed.
+
+.. note:: TODO: There are two fields in the DXIL metadata that are not
+   represented as part of the target type: ``IsGloballyCoherent`` and
+   ``HasCounter``.
+
+   Since these are derived from analysis, storing them on the type would mean
+   we need to change the type during the compiler pipeline. That just isn't
+   practical. It isn't entirely clear to me that we need to serialize this info
+   into the IR during the compiler pipeline anyway - we can probably get away
+   with an analysis pass that can calculate the information when we need it.
+
+   If analysis is insufficient we'll need something akin to ``annotateHandle``
+   (but limited to these two properties) or to encode these in the handle
+   creation.
+
+.. _dxil-resources-types-of-resource:
+
+Types of Resource
+=
+
+We define a set of ``TargetExtTypes`` that is similar to the HLSL
+representations for the various resources, albeit with a few things
+parameterized. This is different than DXIL, as simplifying the types to
+something like "dx.srv" and "dx.uav" types would mean the operations on these
+types would have to be overly generic.
+
+Samplers
+
+
+.. code-block:: llvm
+
+   target("dx.Sampler", SamplerType)
+
+The "dx.Sampler" type is used to represent sampler state. The sampler type is
+an enum value from the DXIL ABI, and these appear in sampling operations as
+well as LOD calculations and texture gather.
+
+Constant Buffers
+
+
+.. code-block:: llvm
+
+   target("dx.CBuffer", BufferSize)
+
+The "dx.CBuffer" type is a constant buffer of the given size. Note that despite
+the name this is distinct from the buffer types, and can only be read using the
+"dx.CBufferLoad" and "dx.CBufferLoadLegacy" operations.
+
+Buffers
+---
+
+.. code-block:: llvm
+
+   target("dx.Buffer", ElementType, IsWriteable, IsROV)
+
+There is only one buffer type. This can represent both UAVs and SRVs via the
+``IsWriteable`` field. Since the type that's encoded is an llvm type, it
+handles both ``Buffer`` and ``StructuredBuffer`` uniformly. For ``RawBuffer``,
+the type is ``i8``, which is unambiguous since ``char

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an
+   index into a dynamic resource heap.
+
+   In LLVM we represent binding information in the arguments of the
+   :ref:`handle creation intrinsics `. When generating
+   DXIL we transform these calls to metadata, ``dx.op.createHandle``,
+   ``dx.op.createHandleFromBinding``, ``dx.op.createHandleFromHeap``, and
+   ``dx.op.createHandleForLib`` as needed.
+
+`Type information`
+   The type of data that's accessible via the resource. For buffers and
+   textures this can be a simple type like ``float`` or ``float4``, a struct,
+   or raw bytes. For constant buffers this is just a size. For samplers this is
+   the kind of sampler.
+
+   In LLVM we embed this information as a parameter on the ``target()`` type of
+   the resource. See :ref:`dxil-resources-types-of-resource`.
+
+`Resource kind information`
+   The kind of resource. In HLSL we have things like ``ByteAddressBuffer``,
+   ``RWTexture2D``, and ``RasterizerOrderedStructuredBuffer``. These map to a
+   set of DXIL kinds like ``RawBuffer`` and ``Texture2D`` with fields for
+   certain properties such as ``IsUAV`` and ``IsROV``.
+
+   In LLVM we represent this in the ``target()`` type. We omit information
+   that's deriveable from the type information, but we do have fields to encode
+   ``IsWriteable``, ``IsROV``, and ``SampleCount`` when needed.
+
+.. note:: TODO: There are two fields in the DXIL metadata that are not
+   represented as part of the target type: ``IsGloballyCoherent`` and
+   ``HasCounter``.
+
+   Since these are derived from analysis, storing them on the type would mean
+   we need to change the type during the compiler pipeline. That just isn't
+   practical. It isn't entirely clear to me that we need to serialize this info
+   into the IR during the compiler pipeline anyway - we can probably get away
+   with an analysis pass that can calculate the information when we need it.
+
+   If analysis is insufficient we'll need something akin to ``annotateHandle``
+   (but limited to these two properties) or to encode these in the handle
+   creation.
+
+.. _dxil-resources-types-of-resource:
+
+Types of Resource
+=
+
+We define a set of ``TargetExtTypes`` that is similar to the HLSL
+representations for the various resources, albeit with a few things
+parameterized. This is different than DXIL, as simplifying the types to
+something like "dx.srv" and "dx.uav" types would mean the operations on these
+types would have to be overly generic.
+
+Samplers
+
+
+.. code-block:: llvm
+
+   target("dx.Sampler", SamplerType)
+
+The "dx.Sampler" type is used to represent sampler state. The sampler type is
+an enum value from the DXIL ABI, and these appear in sampling operations as
+well as LOD calculations and texture gather.
+
+Constant Buffers
+
+
+.. code-block:: llvm
+
+   target("dx.CBuffer", BufferSize)
+
+The "dx.CBuffer" type is a constant buffer of the given size. Note that despite
+the name this is distinct from the buffer types, and can only be read using the
+"dx.CBufferLoad" and "dx.CBufferLoadLegacy" operations.
+
+Buffers
+---
+
+.. code-block:: llvm
+
+   target("dx.Buffer", ElementType, IsWriteable, IsROV)
+
+There is only one buffer type. This can represent both UAVs and SRVs via the
+``IsWriteable`` field. Since the type that's encoded is an llvm type, it
+handles both ``Buffer`` and ``StructuredBuffer`` uniformly. For ``RawBuffer``,
+the type is ``i8``, which is unambiguous since ``char

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an

damyanp wrote:

I've always called those "register spaces" (and it seems that's what the linked 
doc calls them as well).

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

[clang] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the DirectX backend into metadata in DXIL.
+
+In DXC and DXIL, static resources are represented as lists of SRVs (Shader
+Resource Views), UAVs (Uniform Access Views), CBVs (Constant Bffer Views), and
+Samplers. This metadata consists of a "resource record ID" which uniquely
+identifies a resource and type information. As of shader model 6.6, there are
+also dynamic resources, which forgo the metadata and are described via
+``annotateHandle`` operations in the instruction stream instead.
+
+In LLVM we attempt to unify some of the alternative representations that are
+present in DXC, with the aim of making handling of resources in the middle end
+of the compiler simpler and more consistent.
+
+Resource Type Information and Properties
+
+
+There are a number of properties associated with a resource in DXIL.
+
+`Resource ID`
+   An arbitrary ID that must be unique per resource type (SRV, UAV, etc).
+
+   In LLVM we don't bother representing this, instead opting to generate it at
+   DXIL lowering time.
+
+`Binding information`
+   Information about where the resource comes from. This is either (a) a
+   binding space, lower bound in that space, and size of the binding, or (b) an

damyanp wrote:

If we want to use some different nomenclature for this here then I think it's 
probably worth explaining that.

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

[clang] [NFC][HLSL] Cleanup TargetInfo handling (PR #90694)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

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

Apologies, it looks like I forgot to submit this review!  Hopefully the 
comments aren't too out of date.

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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

@@ -7398,6 +7398,26 @@ The full documentation is available here: 
https://docs.microsoft.com/en-us/windo
   }];
 }
 
+def HLSLPackOffsetDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The packoffset attribute is used to change the layout of a cbuffer.
+Attribute spelling in HLSL is: ``packoffset( c[Subcomponent][.component] )``.
+A subcomponent is a register number, which is an integer. A component is in 
the form of [.xyzw].
+
+Here're packoffset examples with and without component:

damyanp wrote:

```suggestion
Here are some packoffset examples with and without component:
```

Or:

```suggestion
Examples:
```


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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

@@ -1745,5 +1745,7 @@ def err_hlsl_separate_attr_arg_and_number : Error<"wrong 
argument format for hls
 def ext_hlsl_access_specifiers : ExtWarn<
   "access specifiers are a clang HLSL extension">,
   InGroup;
+def err_hlsl_unsupported_component : Error<"invalid component '%0' used; 
expected 'x', 'y', 'z', or 'w'">;
+def err_hlsl_packoffset_invalid_reg : Error<"invalid resource class specifier 
'%0' for packoffset, expected 'c'">;

damyanp wrote:

Should we document that this is an error, while in DXC it is just a warning, in 
the Clang vs DXC differences page?

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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Support packoffset attribute in AST (PR #89836)

[Damyan Pepper via cfe-commits]

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


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

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

[Damyan Pepper via cfe-commits]

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

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

[Damyan Pepper via cfe-commits]

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


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

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

[Damyan Pepper via cfe-commits]

@@ -4675,7 +4676,7 @@ bool CompilerInvocation::CreateFromArgsImpl(
   // FIXME: We shouldn't have to pass the DashX option around here
   InputKind DashX = Res.getFrontendOpts().DashX;
   ParseTargetArgs(Res.getTargetOpts(), Args, Diags);
-  llvm::Triple T(Res.getTargetOpts().Triple);
+  llvm::Triple T(llvm::Triple::normalize(Res.getTargetOpts().Triple));

damyanp wrote:

Looks like part of this change is to normalize `Res.getTargetOpts().Triple` in 
many places where it is used.

Would it be possible to arrange it so that this is normalized in one place 
earlier on, so all users of `getTargetOpts()` can assume that it is normalized 
already?

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

[clang] [HLSL] Change default linkage of HLSL functions and `groupshared` variables (PR #93336)

[Damyan Pepper via cfe-commits]

@@ -108,3 +108,16 @@ behavior between Clang and DXC. Some examples include:
   diagnostic notifying the user of the conversion rather than silently altering
   precision relative to the other overloads (as FXC does) or generating code
   that will fail validation (as DXC does).
+
+Correctness improvements (bug fixes)
+
+
+Entry point functions & ``static`` keyword
+--
+Marking a shader entry point function ``static`` will result in an error.

damyanp wrote:

Is there a test for this already?

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

[clang] [HLSL] Change default linkage of HLSL functions and `groupshared` variables (PR #93336)

[Damyan Pepper via cfe-commits]

@@ -108,3 +108,16 @@ behavior between Clang and DXC. Some examples include:
   diagnostic notifying the user of the conversion rather than silently altering
   precision relative to the other overloads (as FXC does) or generating code
   that will fail validation (as DXC does).
+
+Correctness improvements (bug fixes)
+
+
+Entry point functions & ``static`` keyword
+--
+Marking a shader entry point function ``static`` will result in an error.

damyanp wrote:

Cool.  Is it significant that these are warnings, while the rst file says 
errors?

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

[clang] [HLSL] Change default linkage of HLSL functions and `groupshared` variables (PR #93336)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

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


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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -536,9 +536,34 @@ DiagnoseHLSLAvailability::FindAvailabilityAttr(const Decl 
*D) {
 void DiagnoseHLSLAvailability::CheckDeclAvailability(NamedDecl *D,
  const AvailabilityAttr 
*AA,
  SourceRange Range) {
-  if (ReportOnlyShaderStageIssues && !AA->getEnvironment())
-return;
 
+  IdentifierInfo *IIEnv = AA->getEnvironment();
+
+  if (!IIEnv) {
+// The availability attribute does not have environment -> it depends only
+// on shader model version and not on specific the shader stage.
+
+// Skip emitting the diagnostics if the diagnostic mode is not set to
+// strict (-fhlsl-strict-availability) because all relevant diagnostics
+// were already emitted in the DiagnoseUnguardedAvailability scan
+// (SemaAvailability.cpp).
+if (SemaRef.getLangOpts().HLSLStrictAvailability)
+  return;

damyanp wrote:

Does returning here mean that it skips emitting diagnostics?  If so, it looks 
like the code skips emitting diagnostics in strict mode, which is the opposite 
of what I think the comment says it is doing.

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -157,6 +157,18 @@ static bool ShouldDiagnoseAvailabilityInContext(
 }
   }
 
+  // In HLSL, emit diagnostic during parsing only if the diagnostic
+  // mode is set to strict (-fhlsl-strict-availability), and either the decl
+  // availability is not restricted to a specific environment/shader stage,
+  // or the target stage is known (= it is not shader library).
+  if (S.getLangOpts().HLSL) {
+if (!S.getLangOpts().HLSLStrictAvailability ||
+(DeclEnv != nullptr &&
+ S.getASTContext().getTargetInfo().getTriple().getEnvironment() ==
+ llvm::Triple::EnvironmentType::Library))
+  return false;
+  }

damyanp wrote:

Nit, and maybe not worth doing, but I had to read this a few times because the 
comment is written in the opposite way to the code.

```suggestion
  if (S.getLangOpts().HLSL) {
bool emitDiagnostics = S.getLangOpts().HLSLStrictAvailability && (
  DeclEnv == nullptr || 
  S.getASTContext().getTargetInfo().getTriple().getEnvironment() !=
llvm::Triple::EnvironmentType::Library);
 
if (!emitDiagnostics)
return false;
  }  
```

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -210,13 +222,16 @@ static bool ShouldDiagnoseAvailabilityInContext(
   return true;
 }
 
-static bool
-shouldDiagnoseAvailabilityByDefault(const ASTContext &Context,
-const VersionTuple &DeploymentVersion,
-const VersionTuple &DeclVersion) {
+static unsigned getAvailabilityDiagnosticKind(

damyanp wrote:

Is `unsigned` really the best type we have for diagnostic kinds?

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -157,6 +157,18 @@ static bool ShouldDiagnoseAvailabilityInContext(
 }
   }
 
+  // In HLSL, emit diagnostic during parsing only if the diagnostic
+  // mode is set to strict (-fhlsl-strict-availability), and either the decl
+  // availability is not restricted to a specific environment/shader stage,
+  // or the target stage is known (= it is not shader library).
+  if (S.getLangOpts().HLSL) {
+if (!S.getLangOpts().HLSLStrictAvailability ||
+(DeclEnv != nullptr &&
+ S.getASTContext().getTargetInfo().getTriple().getEnvironment() ==

damyanp wrote:

Here (and a bit further down in the PR as well) there are places that assume 
that "not library" implies "known target stage". I wonder if we're opening 
ourselves up to subtle bugs issues in the future if we end up adding another 
library-like target?

Maybe this is unlikely enough that we can deal with that later?

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -157,10 +157,12 @@ static bool ShouldDiagnoseAvailabilityInContext(
 }
   }
 
-  // In HLSL, emit diagnostic during parsing only if the diagnostic
-  // mode is set to strict (-fhlsl-strict-availability), and either the decl
-  // availability is not restricted to a specific environment/shader stage,
-  // or the target stage is known (= it is not shader library).
+  // In HLSL, skip emitting diagnostic is the diagnostic mode is not set to

damyanp wrote:

```suggestion
  // In HLSL, skip emitting diagnostic if the diagnostic mode is not set to
```

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -536,9 +536,34 @@ DiagnoseHLSLAvailability::FindAvailabilityAttr(const Decl 
*D) {
 void DiagnoseHLSLAvailability::CheckDeclAvailability(NamedDecl *D,
  const AvailabilityAttr 
*AA,
  SourceRange Range) {
-  if (ReportOnlyShaderStageIssues && !AA->getEnvironment())
-return;
 
+  IdentifierInfo *IIEnv = AA->getEnvironment();
+
+  if (!IIEnv) {
+// The availability attribute does not have environment -> it depends only
+// on shader model version and not on specific the shader stage.
+
+// Skip emitting the diagnostics if the diagnostic mode is not set to
+// strict (-fhlsl-strict-availability) because all relevant diagnostics
+// were already emitted in the DiagnoseUnguardedAvailability scan
+// (SemaAvailability.cpp).
+if (SemaRef.getLangOpts().HLSLStrictAvailability)
+  return;

damyanp wrote:

> Yes, it skips emitting diagnostic here in strict mode because it has already 
> been emitted in the...

Right, but the comment says it skips emitting the diagnostics if it is _not_ in 
strict mode.

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

@@ -157,6 +157,18 @@ static bool ShouldDiagnoseAvailabilityInContext(
 }
   }
 
+  // In HLSL, emit diagnostic during parsing only if the diagnostic
+  // mode is set to strict (-fhlsl-strict-availability), and either the decl
+  // availability is not restricted to a specific environment/shader stage,
+  // or the target stage is known (= it is not shader library).
+  if (S.getLangOpts().HLSL) {
+if (!S.getLangOpts().HLSLStrictAvailability ||
+(DeclEnv != nullptr &&
+ S.getASTContext().getTargetInfo().getTriple().getEnvironment() ==

damyanp wrote:

@llvm-beanz mentioned something this morning that made me think there may be a 
possibility of another environment that isn't a library shader, but also isn't 
tied to a specific shader stage.  I may have misunderstood though.

If we've already got a load of code making this same assumption then maybe now 
isn't the right time to tackle it anyway. Happy for no change here.

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

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

[clang] [HLSL] Strict Availability Diagnostics (PR #93860)

[Damyan Pepper via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/93860
___
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] Implement resource binding type prefix mismatch flag setting logic (PR #97103)

[Damyan Pepper via cfe-commits]

@@ -0,0 +1,104 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - 
-fsyntax-only %s -verify
+
+// TODO: Implement "Buffer"
+struct Eg1 {
+  float f;
+  // Buffer Buf;

damyanp wrote:

This file has a bunch of members and binding annotations commented out.  Is 
that intentional? 

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,406 @@ void SemaHLSL::handleShaderAttr(Decl *D, const ParsedAttr 
&AL) {
 D->addAttr(NewAttr);
 }
 
+struct register_binding_flags {
+  bool resource = false;

damyanp wrote:

>From [what I can 
>tell](https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly)
> this struct and the members of it should all use PascalCase.

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