[all-commits] [llvm/llvm-project] 3cc311: [mlir][Transforms] Dialect Conversion: No target m...

[Matthias Springer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3cc311ab8674eab6b9101cdf3823b55ea23d6535
      https://github.com/llvm/llvm-project/commit/3cc311ab8674eab6b9101cdf3823b55ea23d6535
  Author: Matthias Springer <me at m-sp.org>
  Date:   2024-12-23 (Mon, 23 Dec 2024)

  Changed paths:
    M mlir/lib/Conversion/LLVMCommon/TypeConverter.cpp
    M mlir/lib/Transforms/Utils/DialectConversion.cpp
    M mlir/test/Transforms/test-legalizer.mlir
    M mlir/test/lib/Dialect/Test/TestPatterns.cpp

  Log Message:
  -----------
  [mlir][Transforms] Dialect Conversion: No target mat. for 1:N replacement (#117513)

During a 1:N replacement (`applySignatureConversion` or
`replaceOpWithMultiple`), the dialect conversion driver used to insert
two materializations:

* Argument materialization: convert N replacement values to 1 SSA value
of the original type `S`.
* Target materialization: convert original type to legalized type `T`.

The target materialization is unnecessary. Subsequent patterns receive
the replacement values via their adaptors. These patterns have their own
type converter. When they see a replacement value of type `S`, they will
automatically insert a target materialization to type `T`. There is no
reason to do this already during the 1:N replacement. (The functionality
used to be duplicated in `remapValues` and `insertNTo1Materialization`.)

Special case: If a subsequent pattern does not have a type converter, it
does *not* insert any target materializations. That's because the
absence of a type converter indicates that the pattern does not care
about type legality. Therefore, it is correct to pass an SSA value of
type `S` (or any other type) to the pattern.

Note: Most patterns in `TestPatterns.cpp` run without a type converter.
To make sure that the tests still behave the same, some of these
patterns now have a type converter.

This commit is in preparation of adding 1:N support to the conversion
value mapping. Before making any further changes to the mapping
infrastructure, I'd like to make sure that the code base around it (that
uses the mapping) is robust.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications