[all-commits] [llvm/llvm-project] 5b9106: [mlir] Apply source materialization in case of tra...

ftynse via All-commits all-commits at lists.llvm.org
Thu Feb 4 02:15:37 PST 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5b91060dcc2ef476e9332c5c6d759aed3b05f6be
      https://github.com/llvm/llvm-project/commit/5b91060dcc2ef476e9332c5c6d759aed3b05f6be
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2021-02-04 (Thu, 04 Feb 2021)

  Changed paths:
    M mlir/include/mlir/IR/BlockAndValueMapping.h
    M mlir/lib/Transforms/Utils/DialectConversion.cpp
    M mlir/test/Transforms/test-legalize-type-conversion.mlir
    M mlir/test/lib/Dialect/Test/TestOps.td
    M mlir/test/lib/Dialect/Test/TestPatterns.cpp

  Log Message:
  -----------
  [mlir] Apply source materialization in case of transitive conversion

In dialect conversion infrastructure, source materialization applies as part of
the finalization procedure to results of the newly produced operations that
replace previously existing values with values having a different type.
However, such operations may be created to replace operations created in other
patterns. At this point, it is possible that the results of the _original_
operation are still in use and have mismatching types, but the results of the
_intermediate_ operation that performed the type change are not in use leading
to the absence of source materialization. For example,

  %0 = dialect.produce : !dialect.A
  dialect.use %0 : !dialect.A

can be replaced with

  %0 = dialect.other : !dialect.A
  %1 = dialect.produce : !dialect.A  // replaced, scheduled for removal
  dialect.use %1 : !dialect.A

and then with

  %0 = dialect.final : !dialect.B
  %1 = dialect.other : !dialect.A    // replaced, scheduled for removal
  %2 = dialect.produce : !dialect.A  // replaced, scheduled for removal
  dialect.use %2 : !dialect.A

in the same rewriting, but only the %1->%0 replacement is currently considered.

Change the logic in dialect conversion to look up all values that were replaced
by the given value and performing source materialization if any of those values
is still in use with mismatching types. This is performed by computing the
inverse value replacement mapping. This arguably expensive manipulation is
performed only if there were some type-changing replacements. An alternative
could be to consider all replaced operations and not only those that resulted
in type changes, but it would harm pattern-level composability: the pattern
that performed the non-type-changing replacement would have to be made aware of
the type converter in order to call the materialization hook.

Reviewed By: rriddle

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




More information about the All-commits mailing list