[mlir] fix wrong symbol order in AffineApplyNormalizer
authorAlex Zinenko <zinenko@google.com>
Thu, 27 Feb 2020 13:45:54 +0000 (14:45 +0100)
committerAlex Zinenko <zinenko@google.com>
Thu, 27 Feb 2020 14:15:29 +0000 (15:15 +0100)
commit54e5600e4d28535d4296a6b6baeefccc9cc9d904
tree1cfa000919e649a1461a69354c65b59380e13068
parentaa324c5441f229bd1ff07407affeab95740328fe
[mlir] fix wrong symbol order in AffineApplyNormalizer

Summary:
AffineApplyNormalizer provides common logic for folding affine maps that appear
in affine.apply into other affine operations that use the result of said
affine.apply. In the process, affine maps of both operations are composed.
During the composition `A.compose(B)` the symbols from the map A are placed
before those of the map B in a single concatenated symbol list. However,
AffineApplyNormalizer was ordering the operands of the operation being
normalized by iteratively appending the symbols into a single list accoridng to
the operand order, regardless of whether these operands are symbols of the
current operation or of the map that is being folded into it. This could lead
to wrong order of symbols and, when the symbols were bound to constant values,
to visibly incorrect folding of constants into affine maps as reported in
PR45031. Make sure symbols operands to the current operation are always placed
before symbols coming from the folded maps.

Update the test that was exercising the incorrect folder behavior. For some
reason, the order of symbol operands was swapped in the test input compared to
the previous operations, making it easy to assume the correct maps were
produced whereas they were swapping the symbols back due to the problem
described above.

Closes https://bugs.llvm.org/show_bug.cgi?id=45031

Differential Revision: https://reviews.llvm.org/D75247
mlir/include/mlir/Dialect/AffineOps/AffineOps.h
mlir/lib/Dialect/AffineOps/AffineOps.cpp
mlir/test/Dialect/AffineOps/canonicalize.mlir