This is an archive of the discontinued LLVM Phabricator instance.

[mlir] properly support min/max in affine parallelization
ClosedPublic

Authored by ftynse on Dec 7 2020, 6:45 AM.

Details

Summary

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.

Diff Detail

Event Timeline

ftynse created this revision.Dec 7 2020, 6:45 AM
ftynse requested review of this revision.Dec 7 2020, 6:45 AM
wsmoses requested changes to this revision.Dec 7 2020, 12:38 PM
wsmoses added inline comments.
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.

This revision now requires changes to proceed.Dec 7 2020, 12:38 PM
ftynse added inline comments.Dec 7 2020, 1:28 PM
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).

wsmoses accepted this revision.Dec 7 2020, 2:10 PM
This revision is now accepted and ready to land.Dec 7 2020, 2:10 PM
wsmoses added inline comments.Dec 7 2020, 2:12 PM
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.

This revision was automatically updated to reflect the committed changes.