Skip to content

opt: dissolve OpCopyLogical of OpCompositeConstruct in simplification#6746

Open
SteveUrquhart wants to merge 1 commit into
KhronosGroup:mainfrom
SteveUrquhart:fold-copylogical-of-composite
Open

opt: dissolve OpCopyLogical of OpCompositeConstruct in simplification#6746
SteveUrquhart wants to merge 1 commit into
KhronosGroup:mainfrom
SteveUrquhart:fold-copylogical-of-composite

Conversation

@SteveUrquhart

Copy link
Copy Markdown
Contributor

As described in microsoft/DirectXShaderCompiler#8382, this PR adds a new folding rule to deal with the new SPIR-V the optimizer is receiving from dxc since microsoft/DirectXShaderCompiler#7530. By rewriting

 %0 = OpCompositeConstruct %SrcStruct c0 c1 ... cN
 %1 = OpCopyLogical        %DstStruct %0

as

 %1 = OpCompositeConstruct %DstStruct c0' c1' ... cN'

...we can continue to legalize the technically-invalid

%cc = OpCompositeConstruct %ResHolder_block %resourceVar

...which dxc has always emitted.

@s-perron s-perron left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good. However, we usually assume the spir-v is valid coming into the pass is valid, so there is not need to handle cases where it is not. Those can be asserts. The exception to that is if this is part of DXC legalization. DXC is generating invalid code, and we want to handle it to eventually make it valid.

Comment thread source/opt/folding_rules.cpp Outdated
Comment on lines +2173 to +2185
for (uint32_t i = 0; i < num_constituents; ++i) {
const uint32_t cid = src_inst->GetSingleWordInOperand(i);
Instruction* cdef = def_use_mgr->GetDef(cid);
if (cdef->type_id() == expected_type_ids[i]) {
continue;
}
Instruction* constituent_type_inst = def_use_mgr->GetDef(cdef->type_id());
Instruction* expected_type_inst = def_use_mgr->GetDef(expected_type_ids[i]);
if (constituent_type_inst->opcode() == spv::Op::OpTypePointer ||
expected_type_inst->opcode() == spv::Op::OpTypePointer) {
return false;
}
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove this loop and add an assert in the next loop that type for the opcopylogical is not a pointer. If there was a pointer in the struct or array, then the original OpCopyLogical would have been invalid. I don't mind transforming invalid code into different invalid code. I don't like doing a lot of extra work to avoid doing that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I hadn't thought of using assert as a tool.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about physical storage buffer? Could that not be a member? It has a well defined size.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the assert was too much. We still can't fold it, so bailing is the best option, that preserves valid IR. I added a test for PSB pointers.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that physical storage buffer makes a difference. If you have a valid OpCopyLogical, the type for the pointer must be the same in the source and target type, and we would have continued at line 2177.

I still want to know which cases reach line 2183. I believe they are invalid coming into the pass.

Comment thread test/opt/simplification_test.cpp
@SteveUrquhart SteveUrquhart force-pushed the fold-copylogical-of-composite branch from 422ef27 to ab5f507 Compare June 17, 2026 15:54
@SteveUrquhart SteveUrquhart force-pushed the fold-copylogical-of-composite branch from ab5f507 to 8f3ac5d Compare June 18, 2026 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants