[all-commits] [llvm/llvm-project] 731676: [mlir][spirv] Fix nested control flow serialization

[Lei Zhang via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 731676b10dfe684d7f166cb0f85cd6ede1660119
      https://github.com/llvm/llvm-project/commit/731676b10dfe684d7f166cb0f85cd6ede1660119
  Author: Lei Zhang <antiagainst at google.com>
  Date:   2021-12-11 (Sat, 11 Dec 2021)

  Changed paths:
    M mlir/lib/Target/SPIRV/Deserialization/Deserializer.cpp
    M mlir/lib/Target/SPIRV/Deserialization/Deserializer.h
    M mlir/lib/Target/SPIRV/Serialization/SerializeOps.cpp
    M mlir/lib/Target/SPIRV/Serialization/Serializer.cpp
    M mlir/lib/Target/SPIRV/Serialization/Serializer.h
    M mlir/test/Target/SPIRV/loop.mlir

  Log Message:
  -----------
  [mlir][spirv] Fix nested control flow serialization

If we have a `spv.mlir.selection` op nested in a `spv.mlir.loop`
op, when serializing the loop's block, we might need to jump
from the selection op's merge block, which might be different
than the immediate MLIR IR predecessor block. But we still need
to get the block argument from the MLIR IR predecessor block.

Also, if the `spv.mlir.selection` is in the `spv.mlir.loop`'s
header block, we need to make sure `OpLoopMerge` is emitted
in the current block before start processing the nested selection
op. Otherwise we'll see the LoopMerge in the wrong SPIR-V
basic block.

Reviewed By: Hardcode84

Differential Revision: https://reviews.llvm.org/D115560