[mlir][spirv] Non-deterministic structurization in SPIR-V deserializer

[IgWod-IMG]

Currently when the MLIR code is being structured inside the SPIR-V deserializer (run with: mlir-translate --deserialize-spirv example.spv) the order in which regions are structured is non-deterministic. This is because the DenseMap that holds block merge information (blockMergeInfo) uses a pointer to Block as a key. Then when structurizeControlFlow iterates over the map, the order elements are seen across different runs may vary, as pointer will have different addresses across different runs. So far this doesn't negatively affect supported shaders (or at least not to my knowledge), but it makes debugging harder.

Reported as discussed in #127639

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Igor Wodiany (IgWod-IMG)

Currently when the MLIR code is being structured inside the SPIR-V deserializer (run with: `mlir-translate --deserialize-spirv example.spv`) the order in which regions are structured is non-deterministic. This is because the `DenseMap` that holds block merge information (`blockMergeInfo`) uses a pointer to `Block` as a key. Then when `structurizeControlFlow` iterates over the map, the order elements are seen across different runs may vary, as pointer will have different addresses across different runs. So far this doesn't negatively affect supported shaders (or at least not to my knowledge), but it makes debugging harder.

Reported as discussed in #127639

[llvmbot]

@llvm/issue-subscribers-mlir-spirv

Author: Igor Wodiany (IgWod-IMG)

Currently when the MLIR code is being structured inside the SPIR-V deserializer (run with: `mlir-translate --deserialize-spirv example.spv`) the order in which regions are structured is non-deterministic. This is because the `DenseMap` that holds block merge information (`blockMergeInfo`) uses a pointer to `Block` as a key. Then when `structurizeControlFlow` iterates over the map, the order elements are seen across different runs may vary, as pointer will have different addresses across different runs. So far this doesn't negatively affect supported shaders (or at least not to my knowledge), but it makes debugging harder.

Reported as discussed in #127639