vkd3d-shader/ir: Flatten structured control flow instructions.
Merge request reports
Activity
I need to recheck this, add more error handling, and set
compiler->main_block_open
correctly, but it passes all the tests.Questions:
In d3dbc what does the
LABEL
instruction src parameter contain? I assume this instruction adds a block label so I'm using it for that, and currently emit it with an immediate constant.We lose the naming of block label ids. One way to handle this is include the necessary info in the IR to recreate the deleted namings in the backend. Another is add support for names to VSIR. Thoughts?
The new instruction count sometimes gets ahead of the source count. This is handled by writing everything to a new instruction array, and swapping out the old one at the end. Simple and effective for the moment?
Questions:
In d3dbc what does the
LABEL
instruction src parameter contain? I assume this instruction adds a block label so I'm using it for that, and currently emit it with an immediate constant.These look like "label l0", "label l1", etc. in the disassembler. I.e., using VKD3DSPR_LABEL. They'd get called like "call l0", "call l1", etc. LABEL/CALL isn't terribly common though, to the point that I don't think Wine even has tests for them; the vsa/psa assemblers may be the only way to get them.
We lose the naming of block label ids. One way to handle this is include the necessary info in the IR to recreate the deleted namings in the backend. Another is add support for names to VSIR. Thoughts?
I imagine we could do something similar to SPIR-V's OpName if needed, but I don't think we have a strong reason to choose that option over just including e.g. an array with debug names in struct vkd3d_shader_desc.
The new instruction count sometimes gets ahead of the source count. This is handled by writing everything to a new instruction array, and swapping out the old one at the end. Simple and effective for the moment?
Sure.
added 24 commits
-
7f0f75ee...852eefc0 - 20 commits from branch
wine:master
- 2f385a0c - vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
- e257fb7a - vkd3d-shader: Rename shader_instruction_array_add_icb() to...
- 421ba2b3 - vkd3d-shader/ir: Flatten structured control flow instructions.
- be1fe74f - vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
Toggle commit list-
7f0f75ee...852eefc0 - 20 commits from branch
- Resolved by Giovanni Mascellani
- Resolved by Giovanni Mascellani
- Resolved by Giovanni Mascellani
- Resolved by Giovanni Mascellani
So, it seems that the idea is that at any given time a VSIR program either has control flow based on
if
,loop
, etc or based onlabel
andbranch
(which are endowed with CFG structure information anyway). Is that true, or are cases in which the same program can legally have both types of instructions?
- Resolved by Giovanni Mascellani
added 50 commits
-
81b7c667...0c5c18bd - 46 commits from branch
wine:master
- c9a3f2a7 - vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
- 6b9c4bd6 - vkd3d-shader: Rename shader_instruction_array_add_icb() to...
- 05633773 - vkd3d-shader/ir: Flatten structured control flow instructions.
- ec3dced4 - vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
Toggle commit list-
81b7c667...0c5c18bd - 46 commits from branch
- Resolved by Giovanni Mascellani
- Resolved by Giovanni Mascellani
1621 return &flattener->control_flow_info[depth]; 1622 } 1623 1624 return NULL; 1625 } 1626 1627 static enum vkd3d_result cf_flattener_iterate_instruction_array(struct cf_flattener *flattener) 1628 { 1629 struct vkd3d_shader_parser *parser = flattener->parser; 1630 struct vkd3d_shader_instruction_array *instructions; 1631 struct vkd3d_shader_instruction *dst_ins; 1632 bool main_block_open; 1633 size_t i; 1634 1635 instructions = &parser->instructions; 1636 main_block_open = parser->shader_version.type != VKD3D_SHADER_TYPE_HULL; changed this line in version 21 of the diff
I still think that this should be addressed: once a program is in block form every block should be terminated by
ret
,branch
orswitch_monolithic
(maybe there are others I don't remember right now), including the last one. If this doesn't necessarily happens for programs in structured form, then we should add theret
for all shader types.
- Resolved by Giovanni Mascellani