[SPIR-V] Follow-up to #8616: exclude entry functions from function-target decoration

[Matthew Moulton (mmoult)]

Resolve some issues raised on the last pull request. Most notably, fix the interaction between decorations on entry points and decorations on regular functions. The pre-existing test for entry points was not specific enough to catch introduced bug. This has been amended.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[Copilot]

Pull request overview

Prevents entry-point inline SPIR-V decorations from incorrectly targeting source OpFunctions.

Changes:

• Moves ordinary-function attribute handling into SpirvEmitter.
• Excludes entry functions from function-target decorations.
• Strengthens entry-point and diagnostic tests; updates release notes.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tools/clang/lib/SPIRV/SpirvEmitter.cpp	Applies attributes based on entry-point status.
tools/clang/lib/SPIRV/DeclResultIdMapper.cpp	Removes unconditional function decoration.
tools/clang/test/CodeGenSPIRV/inline-spirv/spv.intrinsicDecorate.hlsl	Rejects accidental source-function decoration.
tools/clang/test/CodeGenSPIRV/inline-spirv/spv.intrinsicDecorate.function.error.hlsl	Checks both unsupported function attributes.
tools/clang/test/CodeGenSPIRV/inline-spirv/spv.intrinsicDecorate.entry.hlsl	Adds focused entry-point coverage.
docs/ReleaseNotes.md	Documents function decoration support.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

tools/clang/lib/SPIRV/SpirvEmitter.cpp:1651

• Ray-tracing entries are not covered by processInlineSpirvAttributes: emitEntryFunctionWrapper returns through emitEntryFunctionWrapperForRayTracing at line 15141 before the call at line 15226. Consequently, this new entry-point guard removes the only registration of [[vk::ext_capability]] and [[vk::ext_extension]] for ray-tracing entry functions, so those attributes are silently dropped. Keep decoration excluded, but register capabilities/extensions for ray entries as well.

  if (!isEntry) {
    declIdMapper.decorateWithIntrinsicAttrs(decl, func);
    declIdMapper.registerCapabilitiesAndExtensionsForDecl(decl);
  }

[Damyan Pepper (damyanp)]

This needs to go in the upcoming release section, not the just-release 1.9.2607 one.

[Matthew Moulton (mmoult)]

Apologies for my delay. I believe this is fixed now.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

docs/ReleaseNotes.md:49

• This SPIR-V change is not limited to experimental preview shader models—the implementation and tests cover ordinary ps_6_0/cs_6_0 functions. Placing the note under “Upcoming Preview Release” makes the preceding text incorrectly state that it will not be part of the next non-preview release. Move this SPIR-V section under “Upcoming Release.”

#### SPIR-V

- Functions can now be decorated with inline SPIR-V. `[[vk::ext_capability]]`
  and `[[vk::ext_extension]]` are now honored on ordinary functions
  [#8616](https://github.com/microsoft/DirectXShaderCompiler/pull/8616)
  [#8719](https://github.com/microsoft/DirectXShaderCompiler/pull/8719).

tools/clang/lib/SPIRV/DeclResultIdMapper.cpp:1834

• The comment groups capabilities and extensions with decorations as attributes “consumed by the stage-variable path,” but that path only consumes vk::ext_decorate; capabilities and extensions are module-level and handled separately. Please distinguish these paths so this guidance does not misdescribe why each attribute is excluded here.

  // applied in SpirvEmitter::doFunctionDecl, which excludes entry points. For
  // an entry point, those attributes are consumed by the stage-variable path
  // (they decorate the entry's interface variables, not its OpFunction), so
  // they must not be applied to the source function here.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (1)

tools/clang/lib/SPIRV/DeclResultIdMapper.cpp:1834

• This comment still groups capabilities and extensions with decorations as being consumed by the stage-variable path, but only vk::ext_decorate is handled there; entry-point capabilities/extensions are handled by processInlineSpirvAttributes (as documented in SpirvEmitter.cpp:1642-1645). Please distinguish the two paths to avoid misleading future changes.

  // an entry point, those attributes are consumed by the stage-variable path
  // (they decorate the entry's interface variables, not its OpFunction), so
  // they must not be applied to the source function here.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/ReleaseNotes.md:34

• The release note currently implies that entry functions can be decorated as functions, but this change intentionally excludes entry points and applies their inline decorations to interface variables instead. Scope the feature to ordinary/non-entry functions so users are not promised unsupported entry-function decoration.

- Functions can now be decorated with inline SPIR-V. `[[vk::ext_capability]]`
  and `[[vk::ext_extension]]` are now honored on ordinary functions

[Chris B (llvm-beanz)]

I'm unsure what is going on with the release notes change here, but otherwise this LGTM.

[Chris B (llvm-beanz)]

The release note changes here don't match the functional change. Was this a mis-merge or is there something else going on here?

[Matthew Moulton (mmoult)]

I noticed there were two competing "Bug Fixes" sections, so I was trying to be helpful and clean it up. Looking at other releases, the "Bug Fixes" section comes after the other headers, so the second section was correct.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tools/clang/lib/SPIRV/DeclResultIdMapper.cpp:1834

• This comment still groups all three attributes under the stage-variable path, but only vk::ext_decorate is consumed there; capabilities and extensions are handled by processInlineSpirvAttributes. Please distinguish those paths so the rationale matches the implementation and the updated comment in SpirvEmitter.cpp.

  // ([[vk::ext_decorate]] / [[vk::ext_capability]] / [[vk::ext_extension]]) are
  // applied in SpirvEmitter::doFunctionDecl, which excludes entry points. For
  // an entry point, those attributes are consumed by the stage-variable path
  // (they decorate the entry's interface variables, not its OpFunction), so
  // they must not be applied to the source function here.

docs/ReleaseNotes.md:36

• Please narrow this release note and remove the two PR links. The current wording implies every inline-SPIR-V decoration is supported on functions, while the accompanying error test confirms that vk::ext_decorate_id and vk::ext_decorate_string are not; additionally, CONTRIBUTING.md:138-140 requires a single-sentence entry without links to specific PRs.

- Functions can now be decorated with inline SPIR-V. `[[vk::ext_capability]]`
  and `[[vk::ext_extension]]` are now honored on ordinary functions
  [#8616](https://github.com/microsoft/DirectXShaderCompiler/pull/8616)
  [#8719](https://github.com/microsoft/DirectXShaderCompiler/pull/8719).