[PATCH] D130033: [HLSL] Add resource binding attribute for HLSL.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added inline comments.


================
Comment at: clang/test/SemaHLSL/resource_binding_attr_error.hlsl:15
+// expected-error at +1 {{invalid space specifier 's2' used; expected 'space' followed by an integer, like space1}}
+cbuffer a : register(b0, s2) {
+
----------------
beanz wrote:
> aaron.ballman wrote:
> > python3kgae wrote:
> > > aaron.ballman wrote:
> > > > Isn't this a re-definition of `a` which would cause an error?
> > > The name for cbuffer is not used.
> > > And no error should be reported for re-definition.
> > > 
> > > Discussed with the team, have to keep it like this for back-compat reason.
> > Wow.
> > 
> > Please either add a comment explaining why this bizarre situation gets no diagnostic, or change the identifiers used so nobody else gets confused by this when reading the test file.
> `cbuffer` is really weird (and hopefully someday will disappear entirely). From a language perspective it behaves almost more like a named anonymous namespace than a datatype (yea, I know that sentence makes no sense).
> 
> The functionality that it provides is the ability to group a set of global constant variables so that the CPU-code can pack and provide those constants in known clumps.
> 
> One might ask why have them named at all? Which is a fair question... The names do get exposed via the CPU-side reflection API which supports querying bindings and the like. We _probably_ shouldn't have ever allowed duplicate names, but as long as they have unique "slot" bindings the names don't really matter.
> 
> `cbuffers` are important because we try to strip unused resources from shaders (because resource binding costs time). A `cbuffer` can either be striped entirely or not at all, which prevents individual binding elements from being stripped and simplifies shader calling code so the caller doesn't need to condition binding every individual resource element.
> 
> We have newer structures in the language which can handle all of the use cases for `cbuffer`, however there are still some cases (particularly targeting older versions of windows), where `cbuffer` is still the dominant technique.
Changed the names to avoid confusion.
More comment is added to https://reviews.llvm.org/D129883


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130033/new/

https://reviews.llvm.org/D130033