Previously, we had 2 level of attributes:
- HLSLUnparsedSemantic
- N attributes, one for each known system semantic.
The first was assigned during parsing, and carried no other meaning than
"there is a semantic token". It was then converted to one of the N
attributes later during Sema.
Those attributes also carried informations like "is indexable" or "is
index explicit".
This had a few issues:
- there was no difference between a semantic attribute applied to a
decl, and the effective semantic in the entrypoint use context.
- having the indexable bit was not useful.
- semantic constraints checks were split between .td files and sema.
Also, existing implementation had effective attributes attached to the
type decl or parameters, meaning struct decl reuse across entrypoints of
in a nested type was not supported, even if legal in HLSL.
This PR tried to simplifies semantic attribute by having 3 attributes:
- HLSLUnpasedSemantic
- HLSLParsedSemantic
- HLSLAppliedSemantic
Initial parsing emits an `HLSLUnparsedSemantic`. We simply say "here is
an HLSL semantic token", but we don't do any semantic check.
Then, Sema does initial validation and transforms an UnparseSemantic
into a ParsedSemantic. This validates a system semantic is known, or
that the associated type is valid (like uint3 for a ThreadIndex).
Then, once we parse an actual shader entrypoint, we can know how
semantics are used in a real context. This step emits a list of
AppliedSemantic. Those are the actual semantic in use for this specific
entrypoint.
Those attributes are attached to each entrypoint parameter, as a flat
list matching the semantic structure flattening HLSL defines. At this
stage of sema, index collision or other stage compabitility checkes are
carried.
This allows codegen to simply iterate over this list and emit the proper
DXIL or SPIR-V codegen.
This commit adds support for HLSL input semantics. User semantics are
all semantics not starting with `SV_`.
Those semantics ends up with a Location assignment in SPIR-V.
Note: user semantics means Location, but the opposite is not true.
Depending on the stage, some system semantics can rely on a Location
index. This is not implemented in this PR.
This changes the instiantiated_from field to use
`getTemplateInstantiationPattern`, which makes this field work for all
template specialization kinds, not just member templates.
Also adds this field to variables, and adds equivalents for the JSON
dumper as well.
Use static methods `__createFromBinding` and `__createFromImplicitBinding` to initialize resources in resource arrays
instead of calling resource constructors with binding information, per proposal update https://github.com/llvm/wg-hlsl/pull/336.
Test updates include the use of the `llvm-cxxfilt` tool which takes care of demangling of function names for a more readable test baseline.
This is the first PR to implement the semantics proposal:
https://github.com/llvm/wg-hlsl/blob/main/proposals/0031-semantics.md
This PR focuses on the changes required to handle user semantics, but
tried to be almost NFC.
What changes is the error messages as the semantics case is not kept
when reporting error messages.
You might notice the SV_GroupIndex semantic is not properly validated as
are others. This is an existing behavior that we'll need to fix, but
wanted to keep this separated from this rewrite to stay as-close as an
NFC as possible.
The next PR will add support on the different kinds of I/O we can have
using semantics (input, inout param, structs).
- Adds resource constructor that takes explicit binding for all resource
classes.
- Updates implementation of default resource constructor to initialize
resource handle to `poison`.
- Removes initialization of resource classes from Codegen.
- Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime`
because it does not have a corresponding resource class type.
- Adds `ImplicitCastExpr` for builtin function calls. Sema adds these
automatically when a method of a template class is instantiated, but
some resource classes like `ByteAddressBuffer` are not templates so they
need to have this added explicitly.
Design proposal: llvm/wg-hlsl#197
Closes#134154
Implicit bindings will cause very confusing crashes in the backend at
present, so this is intended at least partially as a stop gap until we
get them implemented (see #110722).
However, I do think that this is useful in the longer term as well as an
off-by-default warning, as it is quite easy to miss a binding or two
when using explicit bindings and the results of that can be surprisingly
hard to debug. I've filed #135907 to track turning this into an
off-by-default warning or removing it eventually as we see fit.
Line ending policies were changed in the parent, dccebddb3b80. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.
Translates `RWBuffer` and `StructuredBuffer` resources buffer types to
DirectX target types `dx.TypedBuffer` and `dx.RawBuffer`.
Includes a change of `HLSLAttributesResourceType` from 'sugar' type to
full canonical type. This is required for codegen and other clang
infrastructure to work property on HLSL resource types.
Fixes#95952 (part 2/2)
Replace `element_type*` handles in HLSLExternalSemaSource with
`__hlsl_resource_t` builtin type.
The handle used to be defined as `element_type*` which was used by the
provisional subscript operator implementation. Now that the handle is
`__hlsl_resource_t` the subscript placeholder implementation was updated
to add `element_type* e;` field to the resource struct. and return a
reference to that. This field is just a temporary workaround until the
indexing is implemented properly in llvm/llvm-project#95956, at which
point the field will be removed. This seemed like a better solution than
disabling many of the existing tests that already use the `[]` operator.
One test has to be disabled nevertheless because an error based on
interactions of const and template instantiation (potential bug that can
be investigated once indexing is implemented the right way).
Fixes#84824
The `__builtin_hlsl_create_handle` called from the constructor of
resource buffer class was supposed to initialize the resource handle
based on resource type and registry binding information. It is not
possible to do though that because the registry binding information is
not accessible from the constructor during codegen.
Instead, the handle should be initialized to an empty or null handle
with something like `__builtin_hlsl_create_null_handle`. This PR is
removing `__builtin_hlsl_create_handle` first and the
`__builtin_hlsl_create_null_handle` will be added to the constructor
once the handle type changes to `__hlsl_resource_t` and
HLSLAttributeResourceType is updated to be a canonical type, which will
allow the initialization assignment.
The actual handle initialization based on the registry binding will be
implemented part 2/2 of llvm/llvm-project#105076 once the dependent
tasks are completed.
Part 1/2 of llvm/llvm-project#105076.
This PR introduces new HLSL resource type attribute
`[[hlsl::raw_buffer]]`. Presence of this attribute on a resource handle
means that the resource does not require typed element access. The
attribute will be used on resource handles that represent buffers like
`StructuredBuffer` or `ByteAddressBuffer` and in DXIL it will be
translated to target extension type `dx.RawBuffer`.
Fixes#107907
Introducing a new HLSL resource type attribute `[[contained_type(T)]]`
which describes the "contained type" of a buffer or resource type.
Specifically, the attribute will be used on the resource handle in
templated buffer types like so:
template <typename T> struct RWBuffer {
__hlsl_resource_t [[hlsl::contained_type(T)]] [[hlsl::resource_class(UAV)]] h;
};
Fixes#104855
This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.
This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.
Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.
We should issue a warning whenever a duplicate resource type attribute
is found. Currently we do that only for `resource_class`. This PR fixes
that by checking for duplicate `is_rov` attributes as well.
Also removes unnecessary parenthesis on `is_rov`.
Converts existing resource attributes `[[hlsl::resource_class(..)]]` and
`[[is_rov]]` from declaration attributes to type attributes.
During type attribute processing all HLSL resource type attributes are
validated and collected by `SemaHLSL`
(`SemaHLSL::handleResourceTypeAttr`). At the end of the declaration they
are be combined into a single `HLSLAttributedResourceType` instance
(`SemaHLSL::ProcessResourceTypeAttributes`) that wraps the original type
and stores all of the necessary information about the resource.
`SemaHLSL` will also need to short-term-store the `TypeLoc` information
for the newly created type that will be grabbed by `TypeSpecLocFiller`
soon after it is created.
Updates all places that expected resource attributes on declarations
like resource binding diagnostic, builtin types in
HLSLExternalSemaSource, or codegen.
Also includes implementation of
`TreeTransform<Derived>::TransformHLSLAttributedResourceType` that
enables the use of attributed resource types inside templates.
Fixes#104861
Part 2/2
There are currently no diagnostics being emitted for when a resource is
bound to a register with an incorrect binding type prefix. For example,
a CBuffer type resource should be bound with a a binding type prefix of
'b', but if instead the prefix is 'u', no errors will be emitted. This
PR implements such diagnostics. The focus of this PR is to implement
both the flag setting and diagnostic emisison steps specified in the
relevant spec: https://github.com/microsoft/hlsl-specs/pull/230
The relevant issue is: https://github.com/llvm/llvm-project/issues/57886
This is a continuation / refresh of this PR:
https://github.com/llvm/llvm-project/pull/87578
Much like #98193, this PR takes some more data out of the resource
attribute, specifically the ROV data.
This PR introduces a new attribute called HLSLROVAttr, which contains
data on whether or not the decl the attribute applies to is an ROV.
Tests were added to ensure the attribute is found on the AST.
This attribute may take any boolean condition as an argument. If the
condition is true, then the object the attribute applies to "is" an ROV.
Fixes #https://github.com/llvm/llvm-project/issues/102392
This PR attaches the resource attributes, `HLSLResourceAttr` and
`HLSLResourceClassAttr`, to the handle contained within such resource
classes like `RWBuffer`. CodeGen will now search for fields within HLSL
resource decls, and emit previous data based on attributes on the handle
member. An AST-dump test was added to verify that the resource attribute
is attached to the handle within the resource record decl.
Fixes#98556
---------
Co-authored-by: Justin Bogner <mail@justinbogner.com>
The ability to spell out and specify the resource class is necessary for
testing various resource binding behaviors. Though it is not intended
for users to use this in customized HLSL source code, the ability to
specify the resource class via an attribute is immensely helpful for
writing thorough tests.
This PR introduces a new attribute, hlsl::resource_attribute, that can
only be applied on structs. This attribute only has 1 required argument,
and must be one of:
```
SRV
UAV
CBuffer
Sampler
```
By applying this attribute to a struct, the struct will have the
`HLSLResourceClassAttr` attribute attached to it in the AST
representation, which provides information on the type of resource class
the struct is meant to be.
The resource class data that was originally contained within the
`HLSLResourceAttr` attribute has been removed in favor of this new
attribute, and so certain ast-dump tests need to be modified so that the
same information can be represented via 2 attributes instead of one.
Fixes#98193
---------
Co-authored-by: Damyan Pepper <damyanp@microsoft.com>
`MaybeParseHLSLAnnotations` should be run on Field Decls instead of just
assuming that any colon after a field decl is a bitfield. In the case
that HLSL is the language, the code after the colon may be an
annotation. This PR gives the parser a chance to parse the subsequent
text as if it was an HLSL annotation.
The burden of parsing is now on the HLSL parser, but the actual work
needs to be done in handling every case of an hlsl annotation on a field
decl. SV_DispatchThreadID was straightforward enough to implement in
this PR, and tests have been added that the annotation appears as an
attribute in the AST.
Previously, the `hlsl_annotations_on_struct_members.hlsl` test would
result in an error shown below on the line that declares variable `a` in
struct Eg9:
error: use of undeclared identifier
'SV_DispatchThreadID'
This is because the annotation is parsed as if it was a c++ bit field,
and an identifier
that represents an integer is expected, but not found.
This test ensures that hlsl annotations are parsed when parsing struct
decls.
This test not only ensures we make progress by moving the validation
error from the realm of
C++ and expecting bitfields, to HLSL and a specialized error for the
recognized annotation, but also
validates that the parser does parse the annotation and adds an
attribute to the field decl in the AST.
Fixes https://github.com/llvm/llvm-project/issues/57889
This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.
This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.
In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.
This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
Fixes#59849
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
Added keyword, LangAS and TypeAttrbute for groupshared.
Tanslate it to LangAS with asHLSLLangAS.
Make sure it translated into address space 3 for DirectX target.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D135060
This is first part for support cbuffer/tbuffer.
The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };
More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants
New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.
The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129883
HLSL doesn't support access specifiers. This change has two components:
1) Make default access for classes public
2) Diagnose the use of access specifiers as a clang HLSL extension
As long as the default behavior for access specifiers matches HLSL,
allowing them to be used doesn't cause sourece incompatability with
valid code. As such enabling them as a clang extension seems like a
reasonable approach.
Fixes#55124
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124487
HLSL has a language feature called Semantics which get attached to
declarations like attributes and are used in a variety of ways.
One example of semantic use is here with the `SV_GroupIndex` semantic
which, when applied to an input for a compute shader is pre-populated
by the driver with a flattened thread index.
Differential Revision: https://reviews.llvm.org/D122699
# Conflicts:
# clang/include/clang/Basic/Attr.td
# clang/include/clang/Basic/AttrDocs.td
