[all-commits] [llvm/llvm-project] c1f719: [mlir] harden result type verification in llvm.call

ftynse via All-commits all-commits at lists.llvm.org
Wed Jul 28 09:16:13 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c1f719d1a749eaf4a4964292e3eed6ab2766f2c5
      https://github.com/llvm/llvm-project/commit/c1f719d1a749eaf4a4964292e3eed6ab2766f2c5
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2021-07-28 (Wed, 28 Jul 2021)

  Changed paths:
    M mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp
    M mlir/lib/Conversion/GPUToVulkan/ConvertLaunchFuncToVulkanCalls.cpp
    M mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
    M mlir/test/Conversion/GPUToVulkan/invoke-vulkan.mlir
    M mlir/test/Dialect/LLVMIR/invalid.mlir

  Log Message:
  -----------
  [mlir] harden result type verification in llvm.call

The verifier of the llvm.call operation was not checking for mismatches between
the number of operation results and the number of results in the signature of
the callee. Furthermore, it was possible to construct an llvm.call operation
producing an SSA value of !llvm.void type, which should not exist. Add the
verification and treat !llvm.void result type as absence of call results.
Update the GPU conversions to LLVM that were mistakenly assuming that it was
fine for llvm.call to produce values of !llvm.void type and ensure these calls
do not produce results.

Reviewed By: mehdi_amini

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


  Commit: 49f745f59cbe1eda4653d917cc7d8d0b586fc6a4
      https://github.com/llvm/llvm-project/commit/49f745f59cbe1eda4653d917cc7d8d0b586fc6a4
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2021-07-28 (Wed, 28 Jul 2021)

  Changed paths:
    M mlir/lib/Translation/Translation.cpp

  Log Message:
  -----------
  [mlir] run the verifier before translating a module

In translation from MLIR to another IR, run the MLIR verifier on the parsed
module to ensure only valid modules are given to the translation. Previously,
we would send any module that could be parsed to the translation, including
semantically invalid modules, leading to surprising errors or lack thereof down
the pipeline.

Depends On D106937

Reviewed By: mehdi_amini

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


Compare: https://github.com/llvm/llvm-project/compare/6e8660a7d65a...49f745f59cbe


More information about the All-commits mailing list