[clang] [llvm] [clang] Add tanf16 builtin and support for tan constrained intrinsic (PR #93314)

[Justin Bogner via cfe-commits]

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


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

[clang] cc1: Report an error for multiple actions unless separated by -main-file-name (PR #91140)

[Justin Bogner via cfe-commits]

bogner wrote:

I don't really understand the rationale for this, and it's kind of annoying. 
Most of the compiler's flags behave in the "last one wins" fashion (such as 
`-O2` and `-O0`) and it's always been convenient to add the flag you want at 
the end. Why treat action flags any differently? Also, even if this is 
worthwhile for some reason I haven't considered, why is it an error rather than 
a warning?

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

[clang] [HLSL][CMake] Cache files don't have generator vars (PR #92793)

[Justin Bogner via cfe-commits]

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


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

[clang] [HLSL][CMake] Add clangd and distribution settings (PR #92011)

[Justin Bogner via cfe-commits]

@@ -8,6 +8,12 @@ set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD "DirectX;SPIRV" CACHE 
STRING "")
 
 # HLSL support is currently limted to clang, eventually it will expand to
 # clang-tools-extra too.
-set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra" CACHE STRING "")
 
 set(CLANG_ENABLE_HLSL On CACHE BOOL "")
+
+if (NOT CMAKE_CONFIGURATION_TYPES)
+  set(LLVM_DISTRIBUTION_COMPONENTS
+  "clang;hlsl-resource-headers;clangd"
+  CACHE STRING "")

bogner wrote:

If we're going to define a distribution components we might want `clang-dxc` in 
there as well

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

[clang] [HLSL][CMake] Add clangd and distribution settings (PR #92011)

[Justin Bogner via cfe-commits]

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

Including clang-tools-extra makes sense to me. Setting up the distribution may 
not be as universal but it seems fine too as a default in this cache file.

LGTM

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

[clang] [HLSL][CMake] Add clangd and distribution settings (PR #92011)

[Justin Bogner via cfe-commits]

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

[clang] [clang][SPIR-V] Always add convergence intrinsics (PR #88918)

[Justin Bogner via cfe-commits]

Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= 
Message-ID:
In-Reply-To: 


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


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

[clang] Fix unused private field warning (PR #91500)

[Justin Bogner via cfe-commits]

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

[clang] [HLSL] reenable add packoffset in AST (PR #91474)

[Justin Bogner via cfe-commits]

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


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

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

[Justin Bogner via cfe-commits]

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


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

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

[Justin Bogner via cfe-commits]

bogner wrote:

> > It would be nice to mention in the description what the sanitizer fix was 
> > compared to the original PR.
> 
> Thanks! The fix to address ASAN failure is in commit 
> [8522e36](https://github.com/llvm/llvm-project/commit/8522e3609869d72b7b457a4752149a802be4662d)
>  of this PR. Updated the description as well.

Since we squash commits when we merge it doesn't really make sense to refer to 
the hash of the PR in the description - this won't point at anything meaningful 
once the change is merged and the PR commits get garbage collected.

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

[clang] [HLSL] reenable add packoffset in AST (PR #91474)

[Justin Bogner via cfe-commits]

bogner wrote:

When reapplying a change that was reverted, please include enough information 
in the description so that it can be understood without having to dig up the 
old change. Something like:

> [HLSL] reenable add packoffset in AST
>
> This reapplies c5509fedc575 "[HLSL] Support packoffset attribute in AST 
> (#89836)" with a fix for the test failure caused by missing 
> -fnative-half-type.
> 
> Since we have to parse the attribute manually in ParseHLSLAnnotations, we 
> could create the ParsedAttribute with a integer offset parameter instead of 
> string. This approach avoids parsing the string if the offset is saved as a 
> string in HLSLPackOffsetAttr.

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

[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

[Justin Bogner via cfe-commits]

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


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

[Justin Bogner via cfe-commits]

@@ -744,7 +744,7 @@ void codegen::setFunctionAttributes(StringRef CPU, 
StringRef Features,
 Expected>
 codegen::createTargetMachineForTriple(StringRef TargetTriple,
   CodeGenOptLevel OptLevel) {
-  Triple TheTriple(TargetTriple);
+  Triple TheTriple(TargetTriple.str());

bogner wrote:

This looks redundant - doesn't Triple's constructor do the conversion to 
`std::string` from Twine internally?

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)

[Justin Bogner via cfe-commits]

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

Other than [my comment 
here](https://github.com/llvm/llvm-project/pull/90809/files#r1589771652) about 
what to do in getArchName this looks reasonable.

The string handling in `normalize` feels a bit unwieldy, but I don't have any 
obvious thoughts for how to simplify it.

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)

[Justin Bogner via cfe-commits]

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

[Justin Bogner via cfe-commits]

@@ -115,6 +115,30 @@ StringRef Triple::getArchName(ArchType Kind, SubArchType 
SubArch) {
 if (SubArch == AArch64SubArch_arm64e)
   return "arm64e";
 break;
+  case Triple::dxil:
+switch (SubArch) {
+case Triple::NoSubArch:
+case Triple::DXILSubArch_v1_0:
+  return "dxilv1.0";
+case Triple::DXILSubArch_v1_1:
+  return "dxilv1.1";
+case Triple::DXILSubArch_v1_2:
+  return "dxilv1.2";
+case Triple::DXILSubArch_v1_3:
+  return "dxilv1.3";
+case Triple::DXILSubArch_v1_4:
+  return "dxilv1.4";
+case Triple::DXILSubArch_v1_5:
+  return "dxilv1.5";
+case Triple::DXILSubArch_v1_6:
+  return "dxilv1.6";
+case Triple::DXILSubArch_v1_7:
+  return "dxilv1.7";
+case Triple::DXILSubArch_v1_8:
+  return "dxilv1.8";
+default:
+  return "";

bogner wrote:

I would argue that returning an empty string here is just as inconsistent as 
erroring out/crashing. We should probably just do (2) even though it's 
obviously ridiculous, since for other architectures if you provide an invalid 
subarch they are indeed just as ridiculous.

If we want to shore this up so that invalid sub architectures do something more 
sensible we should do it for all targets and in a separate change.

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)

[Justin Bogner via cfe-commits]

@@ -744,7 +744,7 @@ void codegen::setFunctionAttributes(StringRef CPU, 
StringRef Features,
 Expected>
 codegen::createTargetMachineForTriple(StringRef TargetTriple,
   CodeGenOptLevel OptLevel) {
-  Triple TheTriple(TargetTriple);
+  Triple TheTriple(llvm::Triple::normalize(TargetTriple.str()));

bogner wrote:

It's a bit of a grey area because this function is only really used by testing 
tools but I don't think we should normalize here. If someone is running 
llvm-reduce or one of the fuzzers on a module with an invalid triple they may 
well be doing that intentionally.

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)

[Justin Bogner via cfe-commits]

@@ -1200,6 +1224,27 @@ std::string Triple::normalize(StringRef Str) {
 }
   }
 
+  // Normalize DXIL triple if it does not include DXIL version number.
+  // Determine DXIL version number using the minor version number of Shader
+  // Model version specified in target triple, if any. Prior to decoupling DXIL
+  // version numbering from that of Shader Model DXIL version 1.Y corresponds 
to
+  // SM 6.Y. E.g., dxilv1.Y-unknown-shadermodelX.Y-hull
+  if (Components[0] == "dxil") {
+std::string DXILVerStr{"dxilv1."};
+if (Components.size() > 2) {
+  // OS component specified
+  if (Components[2].starts_with("shadermodel6.")) {
+Components[0] = DXILVerStr.append(
+Components[2].drop_front(strlen("shadermodel6.")));
+  } else if (Components[2].starts_with("shadermodel")) {
+// If shader model specified is other than 6.x, set DXIL Version to 1.0
+Components[0] = DXILVerStr.append("0");
+  }
+}

bogner wrote:

This doesn't look right. We've already parsed `Arch` and `OS` above, so I would 
expect this logic to look something like:
```c++
if (Arch == Triple::DXIL && SubArch == Triple::NoSubArch) {
  VersionTuple Ver = OS != Triple::UnknownOS ? 
parseVersionFromName(Components[2]) : VersionTuple();
  if (Ver)
Components[0] = Components[0].append("1.").append(Ver.Minor);
  else (Ver)
// default case...
}
```

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)

[Justin Bogner via cfe-commits]

@@ -630,7 +630,7 @@ extern "C" int optMain(
 }
   }
 
-  Triple ModuleTriple(M->getTargetTriple());
+  Triple ModuleTriple(Triple::normalize(M->getTargetTriple()));

bogner wrote:

Similarly to my concern about updating `createTargetMachineForTriple`, I don't 
think opt should messing with the triple it's given.

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)

[Justin Bogner 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));

bogner wrote:

IIUC `getTargetOpts().Triple` should *already* be normalized. The definition of 
the option includes a "Normalizer", like so:
```
def triple : Separate<["-"], "triple">,
  HelpText<"Specify target triple (e.g. i686-apple-darwin9)">,
  MarshallingInfoString, 
"llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">,
  AlwaysEmit, Normalizer<"normalizeTriple">;
```

So I think we shouldn't need the call to normalizer in CompilerInvocation at 
all, and we should look at the other places we're adding it to make sure they 
all make sense.

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] [NFC][HLSL] Cleanup TargetInfo handling (PR #90694)

[Justin Bogner via cfe-commits]

https://github.com/bogner 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] [llvm] [DirectX] Start documenting DXIL Resource handling (PR #90553)

[Justin Bogner 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

bogner wrote:

Other than a different but very similar enum I'm not sure how we would abstract 
this. FWIW, the set of sampler types is pretty small:

```c++
enum class SamplerKind : unsigned {
  Default = 0,
  Comparison,
  Mono,
  Invalid,
};
```

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)

[Justin Bogner 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

bogner wrote:

It's called "bind space" in 
https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#metadata-resource-records
 for whatever reason. I can update to use register space instead, as I do think 
that's more common.

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)

[Justin Bogner 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 

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

[Justin Bogner 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 

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

[Justin Bogner 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.

bogner wrote:

Not exactly, but this isn't the right place to discuss the legacy operation. I 
touch on it briefly in the "Constant Buffer Loads" section and I've updated 
this part to just mention `llvm.dx.cbufferLoad`

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

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

[Justin Bogner 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

bogner wrote:

It's the "space" in `register(t3,  space0)`. From 
https://learn.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl:

> The space keyword specifies to which logical register space the declared 
> variable is bound. If the space keyword is omitted, then the default space 
> index of 0 is implicitly assigned to the range (so the tex2 range above 
> resides in space0). register(t3, space0) will never conflict with 
> register(t3, space1), nor with any array in another space that might include 
> t3.

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)

[Justin Bogner 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

bogner wrote:

Yes. The information in the metadata in DXIL is represented in the create 
handle calls and target types.

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] Implement resource binding type prefix mismatch errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef VarTy = "";
+  if (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);
+
+  if (Slot[0] != 't')
+S.Diag(ArgLoc,
+   diag::err_hlsl_mismatching_register_builtin_type_and_name)
+<< Slot.substr(0, 1) << typestr << "'t'";
+  return;
+}
+
+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();
+if (!Attr)
+  llvm_unreachable("Resource class should have a resource attribute.");
+
+DeclResourceClass = Attr->getResourceClass();
+VarTy = TheRecordDecl->getName();
+  } else {
+DeclResourceClass = llvm::hlsl::ResourceClass::CBuffer;
+  }
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+if (Slot[0] == 't')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+if (Slot[0] == 'u')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+// could be CBuffer or TBuffer
+if (CBufferOrTBuffer->isCBuffer()) {
+  VarTy = "cbuffer";
+  if (Slot[0] == 'b')
+return;

bogner wrote:

This will likely crash once we add the 
[ConstantBuffer](https://learn.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl#constant-buffers)
 template syntax, since we'll be able to have:
```hlsl
struct S {
  float4 g_MaxThreadIter;
  float4 g_Window;
};
ConstantBuffer cb0 : register(b0);
```

We should at the very least put a TODO here, but maybe if we can drive 
cbuffer/tbuffer from attributes we could just do the right thing already?

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

[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef VarTy = "";
+  if (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);
+
+  if (Slot[0] != 't')
+S.Diag(ArgLoc,
+   diag::err_hlsl_mismatching_register_builtin_type_and_name)
+<< Slot.substr(0, 1) << typestr << "'t'";
+  return;
+}
+
+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();
+if (!Attr)
+  llvm_unreachable("Resource class should have a resource attribute.");
+
+DeclResourceClass = Attr->getResourceClass();
+VarTy = TheRecordDecl->getName();
+  } else {
+DeclResourceClass = llvm::hlsl::ResourceClass::CBuffer;
+  }
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+if (Slot[0] == 't')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+if (Slot[0] == 'u')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+// could be CBuffer or TBuffer
+if (CBufferOrTBuffer->isCBuffer()) {
+  VarTy = "cbuffer";
+  if (Slot[0] == 'b')
+return;
+} else {
+  VarTy = "tbuffer";
+  // This isn't an SRV, but we need the diagnostic to emit
+  // the same binding prefix that would be expected on an SRV.
+  DeclResourceClass = llvm::hlsl::ResourceClass::SRV;

bogner wrote:

This comment isn't exactly correct. A `tbuffer` *is* an SRV, we simply don't 
have a `ClassDecl` with the annotation to get that information from. I wonder 
if it would be better to put attributes on `HLSLBufferDecl` (perhaps in 
`SemaHLSL::ActOnStartBuffer`) so that we can drive the two ways of getting here 
in the same way.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

@@ -2,39 +2,45 @@
 
 // Supported targets
 //
-// RUN: %clang -target dxil--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-pixel %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil--shadermodel6.2-library %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-library %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 
| FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2-unknown-shadermodel6.2-pixel %s -S -o 
/dev/null 2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2--shadermodel6.2-library %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2-unknown-shadermodel6.2-library %s -S -o 
/dev/null 2>&1 | FileCheck --check-prefix=CHECK-VALID %s
 
 // Empty shader model
 //
-// RUN: not %clang -target dxil %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-NO-OS %s
+// RUN: not %clang -target dxilv1.2 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-NO-OS %s
 
 // Invalid shader models
 //
-// RUN: not %clang -target dxil--linux %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--win32 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--unknown %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--invalidos %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--linux %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--win32 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--unknown %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--invalidos %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
 
 // Bad shader model versions. Currently we just check for any version at all.
 //
-// RUN: not %clang -target dxil--shadermodel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--shadermodel0.0 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--shadermodel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--shadermodel0.0 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
 
 // Empty shader stage
 //
-// RUN: not %clang -target dxil-shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
-// RUN: not %clang -target dxil--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
-// RUN: not %clang -target dxil--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2-shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s

bogner wrote:

What should happen if someone specifies `dxilv1.0--shadermodel6.7` and then 
uses some SM6.7 feature that isn't representable in dxil 1.0? We should 
probably validate that the dxil version and shadermodel are compatible.

A 1-1 mapping for validating the shader model vs the dxil version is probably 
sufficient / matches DXC. It's also possible we could do better, but I don't 
know that it's worth the effort of cataloguing compatibility for that.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

@@ -115,6 +115,30 @@ StringRef Triple::getArchName(ArchType Kind, SubArchType 
SubArch) {
 if (SubArch == AArch64SubArch_arm64e)
   return "arm64e";
 break;
+  case Triple::dxil:
+switch (SubArch) {
+case Triple::DXILSubArch_v1_0:
+  return "dxilv1.0";
+case Triple::DXILSubArch_v1_1:
+  return "dxilv1.1";
+case Triple::DXILSubArch_v1_2:
+  return "dxilv1.2";
+case Triple::DXILSubArch_v1_3:
+  return "dxilv1.3";
+case Triple::DXILSubArch_v1_4:
+  return "dxilv1.4";
+case Triple::DXILSubArch_v1_5:
+  return "dxilv1.5";
+case Triple::DXILSubArch_v1_6:
+  return "dxilv1.6";
+case Triple::DXILSubArch_v1_7:
+  return "dxilv1.7";
+case Triple::DXILSubArch_v1_8:
+  return "dxilv1.8";
+default:
+  report_fatal_error("Unknown DXIL Version",
+ /*gen_crash_diag=*/false);

bogner wrote:

I don't think we should crash if we have an architecture without a subarch. We 
don't for any of the other architectures.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

@@ -2,39 +2,45 @@
 
 // Supported targets
 //
-// RUN: %clang -target dxil--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-pixel %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil--shadermodel6.2-library %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-library %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 
| FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2-unknown-shadermodel6.2-pixel %s -S -o 
/dev/null 2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2--shadermodel6.2-library %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-VALID %s
+// RUN: %clang -target dxilv1.2-unknown-shadermodel6.2-library %s -S -o 
/dev/null 2>&1 | FileCheck --check-prefix=CHECK-VALID %s
 
 // Empty shader model
 //
-// RUN: not %clang -target dxil %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-NO-OS %s
+// RUN: not %clang -target dxilv1.2 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-NO-OS %s
 
 // Invalid shader models
 //
-// RUN: not %clang -target dxil--linux %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--win32 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--unknown %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--invalidos %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--linux %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--win32 %s -S -o /dev/null 2>&1 | FileCheck 
--check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--unknown %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--invalidos %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
 
 // Bad shader model versions. Currently we just check for any version at all.
 //
-// RUN: not %clang -target dxil--shadermodel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
-// RUN: not %clang -target dxil--shadermodel0.0 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--shadermodel %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
+// RUN: not %clang -target dxilv1.2--shadermodel0.0 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-OS %s
 
 // Empty shader stage
 //
-// RUN: not %clang -target dxil-shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
-// RUN: not %clang -target dxil--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
-// RUN: not %clang -target dxil--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2-shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2 %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-NO-ENV %s
 
 // Invalid shader stages
 //
-// RUN: not %clang -target dxil--shadermodel6.2-unknown %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV %s
-// RUN: not %clang --target=dxil--shadermodel6.2-invalidenvironment %s -S -o 
/dev/null 2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV-DRV %s
-// RUN: not %clang -target dxil--shadermodel6.2-eabi %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-ENV %s
-// RUN: not %clang -target dxil--shadermodel6.2-msvc %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2-unknown %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV %s
+// RUN: not %clang --target=dxilv1.2--shadermodel6.2-invalidenvironment %s -S 
-o /dev/null 2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV-DRV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2-eabi %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV %s
+// RUN: not %clang -target dxilv1.2--shadermodel6.2-msvc %s -S -o /dev/null 
2>&1 | FileCheck --check-prefix=CHECK-BAD-ENV %s
+
+// Invaliddxil target with no version number
+// RUN: not %clang -target dxil--shadermodel6.2-msvc %s -S -o /dev/null 2>&1 | 
FileCheck --check-prefix=CHECK-BAD-TARGET %s

bogner wrote:

So is the `dxil` arch with no subarch just completely disallowed then? This is 
unusual compared to other targets, and also a bit inconvenient for testing. If 
I'm trying something locally and switching 

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

@@ -98,9 +103,47 @@ std::optional tryParseProfile(StringRef 
Profile) {
   else if (llvm::getAsUnsignedInteger(Parts[2], 0, Minor))
 return std::nullopt;
 
-  // dxil-unknown-shadermodel-hull
+  // Determine DXIL version number using the minor version number of Shader
+  // Model version specified in target profile. Prior to decoupling DXIL 
version
+  // numbering from that of Shader Model DXIL version 1.Y corresponds to SM 
6.Y.
+  // E.g., dxilv1.Y-unknown-shadermodelX.Y-hull
   llvm::Triple T;
-  T.setArch(Triple::ArchType::dxil);
+  Triple::SubArchType SubArch = llvm::Triple::NoSubArch;
+  switch (Minor) {
+  case 0:
+SubArch = llvm::Triple::DXILSubArch_v1_0;
+break;
+  case 1:
+SubArch = llvm::Triple::DXILSubArch_v1_1;
+break;
+  case 2:
+SubArch = llvm::Triple::DXILSubArch_v1_2;
+break;
+  case 3:
+SubArch = llvm::Triple::DXILSubArch_v1_3;
+break;
+  case 4:
+SubArch = llvm::Triple::DXILSubArch_v1_4;
+break;
+  case 5:
+SubArch = llvm::Triple::DXILSubArch_v1_5;
+break;
+  case 6:
+SubArch = llvm::Triple::DXILSubArch_v1_6;
+break;
+  case 7:
+SubArch = llvm::Triple::DXILSubArch_v1_7;
+break;
+  case 8:
+  case OfflineLibMinor:
+// Always consider minor version x as the latest supported minor version
+SubArch = llvm::Triple::DXILSubArch_v1_8;

bogner wrote:

It might make updates here less error prone if we added `DXILSubArch_v1_x = 
DXILSubArch_v1_8` or `LastDXILSubArch = DXILSubArch_v1_8` to the enum in 
Triple.h, depending on which of those makes more logical sense.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

@@ -1171,18 +1181,27 @@ TEST(TripleTest, Normalization) {
   Triple::getOSTypeName(FirstOSType),
   Triple::getEnvironmentTypeName(FirstEnvType)};
   for (int Arch = FirstArchType; Arch <= Triple::LastArchType; ++Arch) {
-StringRef C[] = {InitialC[0], InitialC[1], InitialC[2], InitialC[3]};
-C[0] = Triple::getArchTypeName(Triple::ArchType(Arch));
-std::string E = Join(C[0], C[1], C[2]);
-int I[] = {0, 1, 2};
-do {
-  EXPECT_EQ(E, Triple::normalize(Join(C[I[0]], C[I[1]], C[I[2]])));
-} while (std::next_permutation(std::begin(I), std::end(I)));
-std::string F = Join(C[0], C[1], C[2], C[3]);
-int J[] = {0, 1, 2, 3};
-do {
-  EXPECT_EQ(F, Triple::normalize(Join(C[J[0]], C[J[1]], C[J[2]], 
C[J[3]])));
-} while (std::next_permutation(std::begin(J), std::end(J)));
+// Valid DXIL ArchTypes are changed to include version number as SubArch
+// type.
+
+// Exclude testing DXIL Arch since arch type name for Triple::dxil depends
+// on SubArch and is no longer "dxil". Instead, normalization tests for
+// Triple::dxil are added at an earlier location in this test function.
+if (Arch != Triple::dxil) {

bogner wrote:

This is more evidence that treating DXIL specially here is problematic.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

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

There's a lot of churn here so I'm not 100% sure I saw all of the real changes, 
but I think I got them all. It might be nice to move the NFC parts into their 
own commit (if we actually need them, see my other comments).

I don't think we should treat the DXIL architecture differently than all of the 
other architectures in LLVM like this. More on that in the comments.

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

[clang] [llvm] [DirectX] Set DXIL Version using shader model version in compilation target profile (PR #89823)

[Justin Bogner via cfe-commits]

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

[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -25,6 +25,7 @@ enum class ResourceClass : uint8_t {
   SRV = 0,
   UAV,
   CBuffer,
+  TBuffer,

bogner wrote:

I hadn't noticed this. Xiang's right, this isn't correct. See 
`CGHLSLRuntime::finishCodeGen` - a tbuffer is annotated with a resource class 
of `SRV` as you would expect.

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

[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - 
-fsyntax-only %s -verify
+
+// the below will cause an llvm unreachable, because RWBuffers don't have 
resource attributes yet
+// expected-error@+1  {{invalid register name prefix 'b' for register resource 
type 'RWBuffer' (expected 'u')}}
+RWBuffer a : register(b2, space1);
+
+// the below will cause an llvm unreachable, because RWBuffers don't have 
resource attributes yet

bogner wrote:

This comment is still incorrect.

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

[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7334,6 +7334,100 @@ static void handleHLSLShaderAttr(Sema , Decl *D, 
const ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef VarTy = "";
+  if (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);
+
+  if (Slot[0] != 't')
+S.Diag(ArgLoc,
+   diag::err_hlsl_mismatching_register_builtin_type_and_name)
+<< Slot.substr(0, 1) << typestr << "'t'";
+  return;
+}
+
+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();
+if (!Attr)
+  llvm_unreachable("Resource class should have a resource attribute.");
+
+DeclResourceClass = Attr->getResourceClass();
+VarTy = TheRecordDecl->getName();
+  } else {
+if (CBufferOrTBuffer->isCBuffer()) {
+  DeclResourceClass = llvm::hlsl::ResourceClass::CBuffer;
+  VarTy = "cbuffer";
+} else {
+  DeclResourceClass = llvm::hlsl::ResourceClass::TBuffer;
+  VarTy = "tbuffer";
+}
+  }
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+if (Slot[0] != 't')
+  S.Diag(ArgLoc, 
diag::err_hlsl_mismatching_register_resource_type_and_name)
+  << Slot.substr(0, 1) << VarTy
+  << (unsigned)llvm::hlsl::ResourceClass::SRV;
+break;

bogner wrote:

This code is all a little repetitive. Should we reverse the logic and exit 
early in the valid cases instead, and emit the diagnostic in the fallthrough?

```c++
  switch (DeclResourceClass) {
  case llvm::hlsl::ResourceClass::SRV:
if (Slot[0] == 't')
  return;
  case llvm::hlsl::ResourceClass::UAV:
if (Slot[0] == 'u')
  return;
  // ...
  }
  S.Diag(ArgLoc, diag::err_hlsl_mismatching_register_resource_type_and_name)
  << Slot.substr(0, 1) << VarTy
  << (unsigned)DeclResourceClass;
```

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7334,6 +7334,81 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef varTy = "";
+  if (SamplerUAVOrSRV) {
+const Type *Ty = 
SamplerUAVOrSRV->getType()->getPointeeOrArrayElementType();
+if (!Ty)
+  llvm_unreachable("Resource class should have an element type.");

bogner wrote:

I probably just read too many RFCs, but it'd be better to use "must" rather 
than "should" in this message.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -45,7 +45,7 @@ void foo2() {
   extern RWBuffer U2 : register(u5);
 }
 // FIXME: expect-error once fix 
https://github.com/llvm/llvm-project/issues/57886.
-float b : register(u0, space1);
+// float b : register(u0, space1) {}

bogner wrote:

Shouldn't we be adding the `// expected-error:` here rather than commenting 
this out?

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -478,33 +478,35 @@ void HLSLExternalSemaSource::defineTrivialHLSLTypes() {
 
 /// Set up common members and attributes for buffer types
 static BuiltinTypeDeclBuilder setupBufferType(CXXRecordDecl *Decl, Sema ,
-  ResourceClass RC, ResourceKind 
RK,
-  bool IsROV) {
+  ResourceClass RC) {
   return BuiltinTypeDeclBuilder(Decl)
   .addHandleMember()
-  .addDefaultHandleConstructor(S, RC)
-  .annotateResourceClass(RC, RK, IsROV);
+  .addDefaultHandleConstructor(S, RC);
 }

bogner wrote:

Let's either remove this function (since it isn't buying us all that much at 
this point) or rename it to be specifically about setting up the buffer's 
handle (since that's all it does).

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - 
-fsyntax-only %s -verify
+
+// the below will cause an llvm unreachable, because RWBuffers don't have 
resource attributes yet
+// NOT YET IMPLEMENTED : {{invalid register name prefix 'b' for register type 
'RWBuffer' (expected 'u')}}
+// NOT YET IMPLEMENTED RWBuffer a : register(b2, space1);

bogner wrote:

This seems incorrect - RWBuffer is the one resource type that's actually 
available

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7334,6 +7334,81 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef varTy = "";

bogner wrote:

LLVM style prefers `VarTy`

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

[clang] [clang][SPIR-V] Always add convervence intrinsics (PR #88918)

[Justin Bogner via cfe-commits]

Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= 
Message-ID:
In-Reply-To: 



@@ -3101,3 +3130,68 @@ CodeGenFunction::GenerateCapturedStmtFunction(const 
CapturedStmt ) {
 
   return F;
 }
+
+namespace {
+// Returns the first convergence entry/loop/anchor instruction found in |BB|.
+// std::nullptr otherwise.
+llvm::IntrinsicInst *getConvergenceToken(llvm::BasicBlock *BB) {
+  for (auto  : *BB) {
+auto *II = dyn_cast();
+if (II && llvm::isConvergenceControlIntrinsic(II->getIntrinsicID()))
+  return II;
+  }
+  return nullptr;
+}
+
+} // namespace
+
+llvm::CallBase *
+CodeGenFunction::addConvergenceControlToken(llvm::CallBase *Input,
+llvm::Value *ParentToken) {
+  llvm::Value *bundleArgs[] = {ParentToken};
+  llvm::OperandBundleDef OB("convergencectrl", bundleArgs);
+  auto Output = llvm::CallBase::addOperandBundle(
+  Input, llvm::LLVMContext::OB_convergencectrl, OB, Input);
+  Input->replaceAllUsesWith(Output);
+  Input->eraseFromParent();
+  return Output;
+}
+
+llvm::IntrinsicInst *
+CodeGenFunction::emitConvergenceLoopToken(llvm::BasicBlock *BB,
+  llvm::Value *ParentToken) {
+  CGBuilderTy::InsertPoint IP = Builder.saveIP();
+
+  if (BB->empty())
+Builder.SetInsertPoint(BB);
+  else
+Builder.SetInsertPoint(>front());
+
+  auto CB = Builder.CreateIntrinsic(
+  llvm::Intrinsic::experimental_convergence_loop, {}, {});
+  Builder.restoreIP(IP);
+
+  auto I = addConvergenceControlToken(CB, ParentToken);
+  return cast(I);
+}
+
+llvm::IntrinsicInst *
+CodeGenFunction::getOrEmitConvergenceEntryToken(llvm::Function *F) {
+  auto *BB = >getEntryBlock();
+  auto *token = getConvergenceToken(BB);

bogner wrote:

LLVM naming prefers `Token`

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

[clang] [clang][SPIR-V] Always add convervence intrinsics (PR #88918)

[Justin Bogner via cfe-commits]

Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= 
Message-ID:
In-Reply-To: 



@@ -3101,3 +3130,68 @@ CodeGenFunction::GenerateCapturedStmtFunction(const 
CapturedStmt ) {
 
   return F;
 }
+
+namespace {
+// Returns the first convergence entry/loop/anchor instruction found in |BB|.
+// std::nullptr otherwise.
+llvm::IntrinsicInst *getConvergenceToken(llvm::BasicBlock *BB) {
+  for (auto  : *BB) {
+auto *II = dyn_cast();
+if (II && llvm::isConvergenceControlIntrinsic(II->getIntrinsicID()))
+  return II;
+  }
+  return nullptr;
+}
+
+} // namespace
+
+llvm::CallBase *
+CodeGenFunction::addConvergenceControlToken(llvm::CallBase *Input,
+llvm::Value *ParentToken) {
+  llvm::Value *bundleArgs[] = {ParentToken};
+  llvm::OperandBundleDef OB("convergencectrl", bundleArgs);
+  auto Output = llvm::CallBase::addOperandBundle(
+  Input, llvm::LLVMContext::OB_convergencectrl, OB, Input);
+  Input->replaceAllUsesWith(Output);
+  Input->eraseFromParent();
+  return Output;
+}
+
+llvm::IntrinsicInst *
+CodeGenFunction::emitConvergenceLoopToken(llvm::BasicBlock *BB,
+  llvm::Value *ParentToken) {
+  CGBuilderTy::InsertPoint IP = Builder.saveIP();
+
+  if (BB->empty())
+Builder.SetInsertPoint(BB);
+  else
+Builder.SetInsertPoint(>front());

bogner wrote:

Should this be something like `BB->getFirstInsertionPt()`? That's more concise 
and better behaved around PHI nodes and the like

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

[clang] [llvm] [SPIRV][HLSL] Add mad intrinsic lowering for spirv (PR #89130)

[Justin Bogner via cfe-commits]

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

Yeah, this is definitely better.

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

[clang] [llvm] [SPIRV][HLSL] Add mad intrinsic lowering for spirv (PR #89130)

[Justin Bogner via cfe-commits]

bogner wrote:

This feels complicated and not very scalable. I don't think we should be 
implementing ad-hoc vtables via a map of function pointers.

It might be worth sketching out a design for an API that can handle the various 
cases we're running into here. We need to be able to handle (1) operation maps 
directly to a generic intrinsic, (2) operation maps to a target intrinsic on 
one or both of SPIR-V and DX, (3) operation has a generic expansion for some 
set of targets.

Here's one idea. We currently have the getXIntrinsic methods on HLSL runtime, 
but maybe we should move the abstraction slightly. What if we had CGHLSLRuntime 
or something like an HLSL builtin builder class with methods like "emitMadOp", 
"emitClampOp", etc? Then we could specialize this class with a SPIRV HLSL 
builder and a DirectX HLSL builder, and leave the door open for other specific 
builders (like AMDGPU) or something like a generic CPU version that expands 
more things out later.


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

[clang] [NFC] Rename hlsl semantics to hlsl annotations (PR #89309)

[Justin Bogner via cfe-commits]

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


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

[clang] [clang][SPIR-V] Set AS for the SPIR-V logical triple (PR #88939)

[Justin Bogner via cfe-commits]

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

[clang] [clang][SPIR-V] Set AS for the SPIR-V logical triple (PR #88939)

[Justin Bogner via cfe-commits]

bogner wrote:

> a) Thanks!; b) apologies for the noise; c) this was actually done on purpose, 
> I actively eschewed changing Logical SPIRV because it wasn't actually clear 
> to me if in the long run it'd have the same AS map / would use numerical 1 
> for globals. If Logical SPIRV is going to go with numerical 1 for globals, 
> LGTM (perhaps it's worth reflecting that in 
> [AutoUpgrade.cpp](https://github.com/llvm/llvm-project/blob/75054525ae58f26c86e418382164540760871186/llvm/lib/IR/AutoUpgrade.cpp#L5346)
>  & associated tests, wherein the predicate guards autoupgrades from occuring 
> on Logical SPIRV)!
> 
> As a sidenote, as far as I can tell, this flared up because in LLVM's [SPIRV 
> TargetMachine](https://github.com/llvm/llvm-project/blob/75054525ae58f26c86e418382164540760871186/llvm/lib/Target/SPIRV/SPIRVTargetMachine.cpp#L56)
>  there's no segregation between Logical & Physical SPIRV. Would it be 
> worthwhile to add that?

@Keenuts Do you have thoughts here? I'm not sure there's been much discussion 
around this.

I'm going to go ahead and push this as is to get the tests passing and we 
should follow up as necessary.

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

[clang] [llvm] [clang][CodeGen] Add AS for Globals to SPIR & SPIRV datalayouts (PR #88455)

[Justin Bogner via cfe-commits]

bogner wrote:

Looks like this missed a spot, causing the .hlsl to spir-v tests to fail. I've 
put up a fix in #88939

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

[clang] [clang][NFC] Move more functions to `SemaHLSL` (PR #88354)

[Justin Bogner via cfe-commits]

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


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

[clang] [HLSL] Remove an unnecessary .ll file in clang/test/SemaHLSL/. (PR #87346)

[Justin Bogner via cfe-commits]

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


https://github.com/llvm/llvm-project/pull/87346
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {
+llvm::hlsl::ResourceClass RC;
+std::string varTy = "";
+if (VD) {
+
+  const Type *Ty = VD->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+return;
+  QualType t = ((ElaboratedType *)Ty)->getNamedType();
+  const CXXRecordDecl *RD = Ty->getAsCXXRecordDecl();
+  if (!RD)
+return;
+
+  if (auto TDecl = dyn_cast(RD))
+RD = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  RD = RD->getCanonicalDecl();
+  const auto *Attr = RD->getAttr();
+  if (!Attr)
+return;

bogner wrote:

Actually, is it even correct to just give up in some of these cases? Is it 
possible to get here with a type that isn't a resource, or did we diagnose that 
earlier? If this is possible, we probably need to diagnose that. If it isn't, 
we should probably just verify this with asserts.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {
+llvm::hlsl::ResourceClass RC;
+std::string varTy = "";
+if (VD) {
+
+  const Type *Ty = VD->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+return;
+  QualType t = ((ElaboratedType *)Ty)->getNamedType();
+  const CXXRecordDecl *RD = Ty->getAsCXXRecordDecl();
+  if (!RD)
+return;
+
+  if (auto TDecl = dyn_cast(RD))
+RD = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  RD = RD->getCanonicalDecl();
+  const auto *Attr = RD->getAttr();
+  if (!Attr)
+return;
+
+  RC = Attr->getResourceClass();
+  varTy = RD->getNameAsString();
+} else {
+  if (BD->isCBuffer()) {
+RC = llvm::hlsl::ResourceClass::CBuffer;
+varTy = "cbuffer";
+  } else {
+RC = llvm::hlsl::ResourceClass::CBuffer;
+varTy = "tbuffer";
+  }
+}
+switch (RC) {
+case llvm::hlsl::ResourceClass::SRV: {
+  if (Slot[0] != 't')
+S.Diag(ArgLoc, diag::err_hlsl_mismatching_register_type_and_name)
+<< Slot.substr(0, 1) << varTy << "t";

bogner wrote:

I think clang generally prefers using "select" in the diagnostic rather than 
passing in raw strings like "t" here.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {
+llvm::hlsl::ResourceClass RC;
+std::string varTy = "";

bogner wrote:

This can be `StringRef` - you can get a `StringRef` with `RD->getName()` below 
and the only other assignments are constant strings.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {

bogner wrote:

It's probably worth breaking this logic out into a separate 
`checkHLSLResourceRegType` function. This would improve the readability and we 
can avoid some indentation by using early returns.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {
+llvm::hlsl::ResourceClass RC;
+std::string varTy = "";
+if (VD) {
+
+  const Type *Ty = VD->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+return;
+  QualType t = ((ElaboratedType *)Ty)->getNamedType();

bogner wrote:

Avoid C-style cast

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -119,8 +119,10 @@ struct BuiltinTypeDeclBuilder {
 ResourceKind RK, bool IsROV) {
 if (Record->isCompleteDefinition())
   return *this;
-Record->addAttr(HLSLResourceAttr::CreateImplicit(Record->getASTContext(),
- RC, RK, IsROV));
+HLSLResourceAttr *attr = HLSLResourceAttr::CreateImplicit(
+Record->getASTContext(), RC, RK, IsROV);
+
+Record->addAttr(attr);

bogner wrote:

This doesn't actually change anything, correct? Probably best to leave it as it 
was.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7333,12 +7333,12 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
   } else {
 Slot = Str;
   }
-
+  QualType Ty = ((clang::ValueDecl *)D)->getType();

bogner wrote:

LLVM avoids C-style casting. This would normally be spelled `QualType QT = 
cast(D)->getType();`. In any case, this variable doesn't look like 
it's used.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -482,15 +484,18 @@ static BuiltinTypeDeclBuilder 
setupBufferType(CXXRecordDecl *Decl, Sema ,
   bool IsROV) {
   return BuiltinTypeDeclBuilder(Decl)
   .addHandleMember()
-  .addDefaultHandleConstructor(S, RC)
-  .annotateResourceClass(RC, RK, IsROV);
+  .addDefaultHandleConstructor(S, RC);
 }
 
 void HLSLExternalSemaSource::defineHLSLTypesWithForwardDeclarations() {
   CXXRecordDecl *Decl;
-  Decl = BuiltinTypeDeclBuilder(*SemaPtr, HLSLNamespace, "RWBuffer")
- .addSimpleTemplateParams({"element_type"})
- .Record;
+  Decl =
+  BuiltinTypeDeclBuilder(*SemaPtr, HLSLNamespace, "RWBuffer")
+  .addSimpleTemplateParams({"element_type"})
+  .annotateResourceClass(ResourceClass::UAV, ResourceKind::TypedBuffer,
+ /*IsROV=*/false)
+  .Record;
+

bogner wrote:

Do we actually need to move the `annotateResourceClass` call to the forward 
declaration here, or can we get away with leaving it on the `onCompletion` 
callback? It's unfortunate that we need to repeat the resource class if we have 
to do it this way.

Further, if we do need to move this, `setupBufferType` should be updated to 
remove the extra parameters, or maybe even removed completely since it really 
doesn't do much anymore.

https://github.com/llvm/llvm-project/pull/87578
___
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 errors (PR #87578)

[Justin Bogner via cfe-commits]

@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema , Decl 
*D,
 return;
   }
 
-  // FIXME: check reg type match decl. Issue
-  // https://github.com/llvm/llvm-project/issues/57886.
+  VarDecl *VD = dyn_cast(D);
+  HLSLBufferDecl *BD = dyn_cast(D);
+
+  if (VD || BD) {
+llvm::hlsl::ResourceClass RC;
+std::string varTy = "";
+if (VD) {
+
+  const Type *Ty = VD->getType()->getPointeeOrArrayElementType();
+  if (!Ty)
+return;
+  QualType t = ((ElaboratedType *)Ty)->getNamedType();
+  const CXXRecordDecl *RD = Ty->getAsCXXRecordDecl();
+  if (!RD)
+return;
+
+  if (auto TDecl = dyn_cast(RD))
+RD = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+  RD = RD->getCanonicalDecl();
+  const auto *Attr = RD->getAttr();
+  if (!Attr)
+return;

bogner wrote:

These returns don't look correct - handleHLSLResourceBindingAttr still has work 
to do after this block of code. However, if you break this check out as I 
suggested elsewhere that will resolve this.

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

[clang] [llvm] [HLSL][DXIL][SPIRV] Implementation of an abstraction for intrinsic selection of HLSL backends (PR #87171)

[Justin Bogner via cfe-commits]

bogner wrote:

The `GENERATE_HLSL_INTRINSIC_FUNCTION` abstraction parts of this look fairly 
reasonable, but do we really want/need dx and spirv intrinsics for the "all" 
function? This is trivial to generate pretty generic IR for and I don't really 
see the value of maintaining that the user wrote "all(x)" in source - this 
doesn't even lower to a DXIL operation in the end. Won't simply expanding this 
out to checks on each of the elements be likely to give us better optimization 
opportunities?

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

[Justin Bogner via cfe-commits]

@@ -4117,14 +4117,17 @@ ExprResult Sema::ActOnNumericConstant(const Token , 
Scope *UDLScope) {
   } else if (Literal.isFloatingLiteral()) {
 QualType Ty;
 if (Literal.isHalf){
-  if (getOpenCLOptions().isAvailableOption("cl_khr_fp16", getLangOpts()))
+  if (getLangOpts().HLSL ||
+  getOpenCLOptions().isAvailableOption("cl_khr_fp16", getLangOpts()))
 Ty = Context.HalfTy;
   else {
 Diag(Tok.getLocation(), diag::err_half_const_requires_fp16);
 return ExprError();
   }
 } else if (Literal.isFloat)
   Ty = Context.FloatTy;
+else if (getLangOpts().HLSL && Literal.isLong)
+  Ty = Context.DoubleTy;
 else if (Literal.isLong)
   Ty = Context.LongDoubleTy;

bogner wrote:

Probably better to put the HLSL check under the existing `Literal.isLong` 
check. This better matches the style of the rest of the function and will 
probably be less error-prone if something changes here in the future.

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] [HLSL] Implement floating literal suffixes (PR #87270)

[Justin Bogner via cfe-commits]

https://github.com/bogner 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] [HLSL] Implement floating literal suffixes (PR #87270)

[Justin Bogner via cfe-commits]

https://github.com/bogner edited 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] [llvm] [HLSL][DXIL][SPIRV] Intrinsic unification PR (PR #87034)

[Justin Bogner via cfe-commits]

bogner wrote:

I have some misgivings about abusing the target intrinsic infrastructure like 
this to create "target" intrinsics for a non-existent target. IMO this is 
morally equivalent to just putting all of these intrinsics as generic llvm 
intrinsics (`llvm.thread_id` or `llvm.all`), just with some extra namespacing.

For a long time there has been some appetite for being able to strip the target 
intrinsics for targets you aren't building (see [this very old 
post](https://discourse.llvm.org/t/lets-stop-using-target-specific-intrinsics-in-generic-code/41783)
 or the [commit that split up intrinsic headers 
per-target](https://github.com/llvm/llvm-project/commit/5d986953c8b917bacfaa1f800fc1e242559f76be)).
 I worry that using the target infrastructure but keyed on something other than 
a target is a step in the wrong direction there.

The other concern is just about layering. Today, backends need to handle 
generic LLVM intrinsics and their own intrinsics *only*. This is introducing 
intrinsics that apply across an arbitrary set of backends (DirectX and SPIRV 
today, possibly some GPU or otherwise SIMT backends in the future...). What's 
the contract for who needs to handle them? Can we encode that contract in a way 
that isn't simply best effort as new intrinsics are added? As is, this approach 
makes those problems harder rather than easier.

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

[clang] [llvm] [HLSL][DXIL] HLSL's `round` should follow `roundeven` behavior (PR #87078)

[Justin Bogner via cfe-commits]

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


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

[clang] Add clang_elementwise_builtin_alias (PR #86175)

[Justin Bogner via cfe-commits]

bogner wrote:

Thanks for working on this, but I think that what this shows is that the 
complexity of adding this elementwise alias builtin isn't quite justified by 
the utility. It's certainly convenient to be able to specify the builtins this 
way, but validation is a lot more complicated and I think this will be hard to 
test. Maybe we should consider this a successful experiment but drop the idea 
for now unless we run into a situation where we really need it in the future.

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

[Justin Bogner via cfe-commits]

bogner wrote:

I think it would be helpful to add a section between the usage part and the 
grammar that discusses where and why in the compiler we need access to the 
parsed root signature (ie, in Sema for diagnostics, in the backend to verify 
resource usage matches, and also in the backend to lower to the serialized 
form). This would make it a little clearer why we need the various different 
representations since it will describe what we'll use them for.

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)

[Justin Bogner via cfe-commits]

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

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

[Justin Bogner via cfe-commits]

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

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

[Justin Bogner via cfe-commits]

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

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

[Justin Bogner via cfe-commits]

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

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

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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
+{
+…

bogner wrote:

I didn't mean to put quotes around it, I meant that this is a unicode ellipsis 
(ie, …) rather than three dots to represent an ellipsis (ie, ...). Sorry - it's 
hard to convey that in text since they look the same.

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)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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 : 

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

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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 : 

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

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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 : 

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

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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++

bogner wrote:

Should be "sh", not C++

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)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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++

bogner wrote:

This isn't C++. I think you could use "peg" here based on 
https://pygments.org/docs/lexers/#lexers-for-grammar-notations-like-bnf

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)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: 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
+{
+…

bogner wrote:

sphinx/pygments chokes on the ellipsis here, best to spell it "..."

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)

[Justin Bogner via cfe-commits]

https://github.com/bogner commented:

Ran into some problems when building `clang-docs-html` to look at this, so here 
are some notes on fixing those issues. I'll do another pass on the content next.

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)

[Justin Bogner via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: c++

bogner wrote:

This is hlsl, not c++

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)

[Justin Bogner via cfe-commits]

https://github.com/bogner 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] [HLSL] enforce unsigned types for reversebits (PR #86720)

[Justin Bogner via cfe-commits]

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


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

[clang] [HLSL] enforce unsigned types for reversebits (PR #86720)

[Justin Bogner via cfe-commits]

@@ -54,31 +29,6 @@ uint16_t4 test_bitreverse_ushort4(uint16_t4 p0)
 }
 #endif
 
-// CHECK: define noundef i32 @
-// CHECK: call i32 @llvm.bitreverse.i32(
-int test_bitreverse_int(int p0)
-{
-   return reversebits(p0);
-}

bogner wrote:

Alright, let's get this in as is for now and loop back once the conversion 
story is in better shape.

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

[clang] [HLSL] enforce unsigned types for reversebits (PR #86720)

[Justin Bogner via cfe-commits]

@@ -54,31 +29,6 @@ uint16_t4 test_bitreverse_ushort4(uint16_t4 p0)
 }
 #endif
 
-// CHECK: define noundef i32 @
-// CHECK: call i32 @llvm.bitreverse.i32(
-int test_bitreverse_int(int p0)
-{
-   return reversebits(p0);
-}

bogner wrote:

In that case we might need to document this as a difference from dxc's 
behaviour, which doesn't seem to care whether it's given a signed or unsigned 
int: https://hlsl.godbolt.org/z/xqjvzas1K

TBH I'm a bit worried this will come up a fair amount on existing shaders.

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

[clang] [HLSL] enforce unsigned types for reversebits (PR #86720)

[Justin Bogner via cfe-commits]

@@ -54,31 +29,6 @@ uint16_t4 test_bitreverse_ushort4(uint16_t4 p0)
 }
 #endif
 
-// CHECK: define noundef i32 @
-// CHECK: call i32 @llvm.bitreverse.i32(
-int test_bitreverse_int(int p0)
-{
-   return reversebits(p0);
-}

bogner wrote:

Will these implicitly convert to `uint` now, or are these errors?

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

[Justin Bogner via cfe-commits]

@@ -0,0 +1,20 @@
+// RUN: not %clang_dxc -enable-16bit-types -T cs_6_0 -HV 2016 %s 2>&1  | 
FileCheck -check-prefix=both_invalid %s
+// RUN: not %clang_dxc -enable-16bit-types -T lib_6_4 -HV 2017 %s 2>&1 | 
FileCheck -check-prefix=HV_invalid %s
+// RUN: not %clang_dxc -enable-16bit-types -T cs_6_0 /HV 2021 %s 2>&1  | 
FileCheck -check-prefix=TP_invalid %s
+// RUN: %clang_dxc -enable-16bit-types -T lib_6_4 /HV 2021 %s 2>&1 -###   | 
FileCheck -check-prefix=valid %s
+
+
+// both_invalid: error: enable-16bit-types option only valid when target 
shader model [-T] is >= 6.2 and HLSL Version [-HV] is >= 2021
+// HV_invalid: error: enable-16bit-types option only valid when target shader 
model [-T] is >= 6.2 and HLSL Version [-HV] is >= 2021
+// TP_invalid: error: enable-16bit-types option only valid when target shader 
model [-T] is >= 6.2 and HLSL Version [-HV] is >= 2021

bogner wrote:

It might be nice to parameterize the diagnostic here to just point out which 
thing is wrong rather than list the full set of requirements. Something like:
> "16-bit types are only valid for %select{shader model 6.2|HLSL version 2021}0 
> and above, but this is '%1'"

WDYT?

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)

[Justin Bogner via cfe-commits]

@@ -753,7 +753,10 @@ 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_dxc_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">;
+def err_drv_cc1_hlsl_spirv_fnative_half_type_option_invalid: Error<
+  "fnative-half-type option only valid when hlsl language standard version is 
>= 2021">;

bogner wrote:

When printing option flags in diagnostics they're usually in single quotes and 
include the leading dash, like `'-enable-16bit-types' option is only valid...`

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] Fix for build break introduced by #85662 (PR #85839)

[Justin Bogner via cfe-commits]

bogner wrote:

I've gone ahead and merged this since it fixes the build break. In the future 
when you see a build break, please just revert the breaking change to get the 
build green again and then work on the fixed patch. It's unfair to others using 
trunk to have to wait on a fix for an obvious build break.

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

[clang] [HLSL] Fix for build break introduced by #85662 (PR #85839)

[Justin Bogner via cfe-commits]

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

[clang] [HLSL] Fix for build break introduced by #85662 (PR #85839)

[Justin Bogner via cfe-commits]

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


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

[clang] [llvm] [HLSL] implement `clamp` intrinsic (PR #85424)

[Justin Bogner via cfe-commits]

@@ -132,12 +134,60 @@ static bool expandRcpIntrinsic(CallInst *Orig) {
   return true;
 }
 
+static Intrinsic::ID getCorrectMaxIntrinsic(Type *elemTy,
+Intrinsic::ID clampIntrinsic) {

bogner wrote:

I could see us needing to get a max intrinsic in some other context at some 
point. Maybe a more specific name like `getMaxForClamp` is better.

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

[clang] [llvm] [HLSL] implement `clamp` intrinsic (PR #85424)

[Justin Bogner via cfe-commits]

@@ -252,6 +252,116 @@ double3 ceil(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_ceil)
 double4 ceil(double4);
 
+//===--===//
+// clamp builtins
+//===--===//
+
+/// \fn T clamp(T X, T Min, T Max)
+/// \brief Clamps the specified value \a X to the specified
+/// minimum ( \a Min) and maximum ( \a Max) range.
+/// \param X A value to clamp.
+/// \param Min The specified minimum range.
+/// \param Max The specified maximum range.
+///
+/// Returns The clamped value for the \a X parameter.
+/// For values of -INF or INF, clamp will behave as expected.
+/// However for values of NaN, the results are undefined.
+
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_clamp)
+half clamp(half, half, half);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_clamp)
+half2 clamp(half2, half2, half2);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_clamp)
+half3 clamp(half3, half3, half3);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_elementwise_clamp)
+half4 clamp(half4, half4, half4);
+
+#ifdef __HLSL_ENABLE_16_BIT

bogner wrote:

This is pre-existing, so no change needed here, but maybe we should revisit it 
later. The difference between `_HLSL_16BIT_AVAILABILITY` (for half) and 
guarding with `#ifdef __HLSL_ENABLE_16BIT` (for int16/uint16) feels kind of 
subtle. I worry we could make mistakes here in the future.

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

[clang] [llvm] [HLSL] implement `clamp` intrinsic (PR #85424)

[Justin Bogner via cfe-commits]

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

[clang] [llvm] [HLSL] implement `clamp` intrinsic (PR #85424)

[Justin Bogner via cfe-commits]

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


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