[all-commits] [llvm/llvm-project] 073289: [mlir] LLVM import: handle constant data and array...

ftynse via All-commits all-commits at lists.llvm.org
Mon Jan 27 07:15:30 PST 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 07328944efb6454b74563b61a97d61545888757b
      https://github.com/llvm/llvm-project/commit/07328944efb6454b74563b61a97d61545888757b
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2020-01-27 (Mon, 27 Jan 2020)

  Changed paths:
    M mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp
    M mlir/test/Target/import.ll

  Log Message:
  -----------
  [mlir] LLVM import: handle constant data and array/vector aggregates

Summary:
Implement the handling of llvm::ConstantDataSequential and
llvm::ConstantAggregate for (nested) array and vector types when imporitng LLVM
IR to MLIR. In all cases, the result is a DenseElementsAttr that can be used in
either a `llvm.mlir.global` or a `llvm.mlir.constant`. Nested aggregates are
unpacked recursively until an element or a constant data is found. Nested
arrays with innermost scalar type are represented as DenseElementsAttr of
tensor type. Nested arrays with innermost vector type are represented as
DenseElementsAttr with (multidimensional) vector type.

Constant aggregates of struct type are not yet supported as the LLVM dialect
does not have a well-defined way of modeling struct-type constants.

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


  Commit: 84c3f05c8e3e28fd58c458f842e721bbbaa837b2
      https://github.com/llvm/llvm-project/commit/84c3f05c8e3e28fd58c458f842e721bbbaa837b2
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2020-01-27 (Mon, 27 Jan 2020)

  Changed paths:
    M mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp

  Log Message:
  -----------
  [mlir] Harden error propagation in LLVM import

Summary:
LLVM importer to MLIR was implemented mostly as a prototype. As such, it did
not deal handle errors in a consistent way, reporting them out stderr in some
cases and continuing the execution in the error state until eventually
crashing. This is not desirable for a user-facing tool. Make sure errors are
returned from functions, consistently checked at call sites and propagated
further. Functions returning nullable IR values return nullptr to denote the
error state. Other functions return LogicalResult. LLVM importer in
mlir-translate should no longer crash on unsupported inputs.

The errors are reported without association with the source file (and therefore
cannot be checked using -verify-diagnostics). Attaching them to the actual
input file is left for future work.

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


Compare: https://github.com/llvm/llvm-project/compare/fdaad485e620...84c3f05c8e3e


More information about the All-commits mailing list