[all-commits] [llvm/llvm-project] 96076a: [mlir] Support index and memref types in llvm.mlir...

ftynse via All-commits all-commits at lists.llvm.org
Thu Dec 17 00:22:04 PST 2020


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 96076a2edbd63e3e9d6ee0eca0c90d34579b7602
      https://github.com/llvm/llvm-project/commit/96076a2edbd63e3e9d6ee0eca0c90d34579b7602
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2020-12-17 (Thu, 17 Dec 2020)

  Changed paths:
    M mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
    M mlir/test/Conversion/StandardToLLVM/invalid.mlir
    A mlir/test/Dialect/LLVMIR/dialect-cast.mlir

  Log Message:
  -----------
  [mlir] Support index and memref types in llvm.mlir.cast

This operation is designed to support partial conversion, more specifically the
IR state in which some operations expect or produce built-in types and some
operations produce and expect LLVM dialect types. It is reasonable for it to
support cast between built-in types and any equivalent that could be produced
by the type conversion. (At the same time, we don't want the dialect to depend
on the type conversion as it could lead to a dependency cycle). Introduce
support for casting from index to any integer type and back, and from memref to
bare pointer or memref descriptor type and back.

Contrary to what the TODO in the code stated, there are no particular
precautions necessary to handle the bare pointer conversion for memerfs. This
conversion applies exclusively to statically-shaped memrefs, so we can always
recover the full descriptor contents from the type.

This patch simultaneously tightens the verification for other types to only
accept matching pairs of types, e.g., i64 and !llvm.i64, as opposed to the
previous implementation that only checked if the types were generally allowed
byt not for matching, e.g. i64 could be "casted" to !llvm.bfloat, which is not
the intended semantics.

Move the relevant test under test/Dialect/LLVMIR because it is not specific to
the conversion pass, but rather exercises an op in the dialect. If we decide
this op does not belong to the LLVM dialect, both the dialect and the op should
move together.

Reviewed By: silvas, ezhulenev

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




More information about the All-commits mailing list