Skip to content

[Semantics] Determine attribute types to carry semantic information #359

@Keenuts

Description

@Keenuts

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:

  • HLSLUnparsedSemantic for parsed semantic pre-sema.
  • HLSLSemantic for 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_GroupTheadID would have the index 0, 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

No labels
No labels

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions