The existing implementation of the affine parallelization silently copies over
the lower and upper bound maps from affine.for to affine.parallel. However, the
semantics of these maps differ between these two ops: in affine.for, a max(min)
of results is taken for the lower(upper) bound; in affine.parallel, multiple
induction variables can be defined an each result corresponds to one induction
variable. Thus the existing implementation could generate invalid IR or IR that
passes the verifier but has different semantics than the original code. Fix the
parallelization utility to emit dedicated min/max operations before the
affine.parallel in such cases. Disallow parallelization if min/max would have
been in an operation without the AffineScope trait, e.g., in another loop,
since the result of these operations is not considered a valid affine dimension
identifier and may not be properly handled by the affine analyses.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Affine/Utils/Utils.cpp | ||
---|---|---|
145 | While seeming correct, I am a bit worried that checking for num results > 1 here won't be equivalent to checking if there's a max (or min) in the future if AffineForOp is extended, resulting in this code getting overlooked. |
mlir/lib/Dialect/Affine/Utils/Utils.cpp | ||
---|---|---|
145 | This has been a part of the op's semantics since it was created - https://mlir.llvm.org/docs/Dialects/Affine/#affinefor-affineforop - there's no other way of checking for this (well, unless you want me to introduce the condition in the op itself and update the existing users). |
mlir/lib/Dialect/Affine/Utils/Utils.cpp | ||
---|---|---|
145 | I think that may be useful for clarity to add a helper wrapper to AffineForOp, but not necessary for this patch. |
While seeming correct, I am a bit worried that checking for num results > 1 here won't be equivalent to checking if there's a max (or min) in the future if AffineForOp is extended, resulting in this code getting overlooked.