forked from OSchip/llvm-project
![]() This CL revisits the composition of AffineApplyOp for the special case where a symbol itself comes from an AffineApplyOp. This is achieved by rewriting such symbols into dims to allow composition to occur mathematically. The implementation is also refactored to improve readability. Rationale for locally rewriting symbols as dims: ================================================ The mathematical composition of AffineMap must always concatenate symbols because it does not have enough information to do otherwise. For example, composing `(d0)[s0] -> (d0 + s0)` with itself must produce `(d0)[s0, s1] -> (d0 + s0 + s1)`. The result is only equivalent to `(d0)[s0] -> (d0 + 2 * s0)` when applied to the same mlir::Value* for both s0 and s1. As a consequence mathematical composition of AffineMap always concatenates symbols. When AffineMaps are used in AffineApplyOp however, they may specify composition via symbols, which is ambiguous mathematically. This corner case is handled by locally rewriting such symbols that come from AffineApplyOp into dims and composing through dims. PiperOrigin-RevId: 239791597 |
||
---|---|---|
.. | ||
Vectorize | ||
canonicalize.mlir | ||
constant-fold.mlir | ||
cse.mlir | ||
dma-generate.mlir | ||
loop-fusion.mlir | ||
loop-tiling.mlir | ||
lower-affine.mlir | ||
memref-bound-check.mlir | ||
memref-dataflow-opt.mlir | ||
memref-dependence-check.mlir | ||
parallelism-detection.mlir | ||
pipeline-data-transfer.mlir | ||
simplify-affine-structures.mlir | ||
slicing_utils.mlir | ||
strip-debuginfo.mlir | ||
unroll-jam.mlir | ||
unroll.mlir |