[all-commits] [llvm/llvm-project] 89b595: [mlir][spirv] Detach memory space mapping from typ...

Lei Zhang via All-commits all-commits at lists.llvm.org
Tue Aug 9 11:30:58 PDT 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 89b595e1418b22cd7c982276aa32872863c5e186
  Author: Lei Zhang <antiagainst at google.com>
  Date:   2022-08-09 (Tue, 09 Aug 2022)

  Changed paths:
    M mlir/include/mlir/Conversion/GPUToSPIRV/GPUToSPIRVPass.h
    M mlir/include/mlir/Dialect/SPIRV/Transforms/SPIRVConversion.h
    M mlir/lib/Conversion/GPUToSPIRV/GPUToSPIRV.cpp
    M mlir/lib/Conversion/GPUToSPIRV/GPUToSPIRVPass.cpp
    M mlir/lib/Conversion/MemRefToSPIRV/MemRefToSPIRV.cpp
    M mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
    M mlir/test/Conversion/FuncToSPIRV/types-to-spirv.mlir
    A mlir/test/Conversion/GPUToSPIRV/gpu-to-spirv.mlir
    M mlir/test/Conversion/GPUToSPIRV/load-store.mlir
    A mlir/test/Conversion/GPUToSPIRV/module-opencl.mlir
    R mlir/test/Conversion/GPUToSPIRV/module-structure-opencl.mlir
    R mlir/test/Conversion/GPUToSPIRV/simple.mlir
    M mlir/test/Conversion/LinalgToSPIRV/linalg-to-spirv.mlir
    M mlir/test/Conversion/MemRefToSPIRV/alloc.mlir
    M mlir/test/Conversion/MemRefToSPIRV/alloca.mlir
    M mlir/test/Conversion/MemRefToSPIRV/memref-to-spirv.mlir
    M mlir/test/Conversion/SCFToSPIRV/for.mlir
    M mlir/test/Conversion/SCFToSPIRV/if.mlir
    M mlir/tools/mlir-spirv-cpu-runner/mlir-spirv-cpu-runner.cpp
    M mlir/tools/mlir-vulkan-runner/mlir-vulkan-runner.cpp

  Log Message:
  [mlir][spirv] Detach memory space mapping from type conversion

This commit moves MemRef memory space to SPIR-V storage class
conversion out of the main SPIR-V type converter. Now the mapping
should happen as a prelimiary step before performing the final
conversion to SPIR-V. Flows are expect to write their own memory
space mappings like the `MapMemRefStorageClassPass` to handle
memory space mappings according to their needs.

This is needed because SPIR-V is serving multiple client APIs,
including Vulkan and OpenCL. Different client APIs might want
to use different storage classes for buffers in a particular
memory space, e.g., `StorageBuffer` for Vulkan vs. `CrossWorkgroup`
for OpenCL when converting the default 0 memory space.  Hardcoding
a specific mapping makes that hard. While it's possible to embed
selection logic further inside the main type converter, it will
make the main type converter even complicated. So it's better to
separate the concerns, as mapping the memory space is really
concretizing the meaning of those numeric memory spaces in the
particular context of SPIR-V lowering.

Reviewed By: kuhar

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

More information about the All-commits mailing list