-
Notifications
You must be signed in to change notification settings - Fork 17
Description
Current implementation relies on a few semantic attributes:
HLSLUnparsedSemantic: attribute created for each semantic string found during parsing.HLSLSV_*and HLSLUserSemantic` attributes once semantic has been determined.
Because we want to emit diagnostics with the exact spelling, the attributes currently need to keep a reference on the exact tokens used to declare them.
In addition, those attributes stores the semantic index, as well as an notion of explicit index, and indexable. The idea was to use .td files to write semantic constraints for system semantics, like:
def HLSLSV_Position : HLSLSemanticAttr</* Indexable= */ 1> {
def HLSLSV_GroupThreadID : HLSLSemanticAttr</* Indexable= */ 0> {
This allows sema to handle indexing without knowing much about the semantics. Goal was to avoid switch statements to do semantic validation, and have the .td file be centralized location for constraints.
In practice, this is not true:
- type + semantic validation is still done manually in sema.
- semantic + stage validation is still done manually in sema.
So it might be simpler to consider removing the per-semantic attribute, and fallback on 2 attributes:
HLSLUnparsedSemanticfor parsed semantic pre-sema.HLSLSemanticfor post-sema semantics.
The HLSLSemantic attribute would contain the following informations:
- a reference to the original token for diagnostics.
- the effective semantic index (even if implicit). Semantic with no index like
SV_GroupTheadIDwould have the index0, but it will be ignored (Sema does the isIndexable validation). - an enum storing the system semantic this represents if any, or
TheEnumName::UserSemantic.
Note: there is an open question on how to link those attribute to the entrypoint parameters. I think those can be solved independently: the solution we'll determine to link those can be applied to both the current attribute hierarchy, or the new simpler version. Reference: #358
Note 2: DXIL could require some additional information for signature packing, but this being DXIL specific, I'd assume this should be out-of-scope of this core part. A way to split this problem is consider adding another attribute for each of those semantics like SignaturePackingInfo.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status