This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] Avoid using scf.parallel for non-parallel loops in Linalg ops.
ClosedPublic

Authored by mravishankar on May 19 2020, 12:56 AM.

Details

Summary

Modifying the loop nest builder for generating scf.parallel loops to
not generate scf.parallel loops for non-parallel iterator types in
Linalg operations. The existing implementation incorrectly generated
scf.parallel for all tiled loops. It is rectified by refactoring logic
used while lowering to loops that accounted for this.

Diff Detail

Event Timeline

mravishankar created this revision.May 19 2020, 12:56 AM

I think there are a few issues at this time.
The GenericBuilder is introduced by Linalg because that is the place in spacetime that uses both affine and scf.
This CL ties the implementation of GenericBuilder to more Linalg internals which leaks more abstractions.
I have https://reviews.llvm.org/D80290 which retires a bunch of now unused stuff.
This should make this CL simpler after rebasing.

On the change itself, this does not seem to support interleaving.
I think I would rather try to go for a recursive helper function that takes ArrayRef slices and a leaf lambda but otherwise leaves GenericLoopNestBuilder untouched.
This should also evolve better when we have more loop types.

mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
379

you also want to apply the interchange vector with applyPermutationToVector

mlir/test/Dialect/Linalg/tile_parallel_reduce.mlir
109

nit: newline

nicolasvasilache requested changes to this revision.May 20 2020, 5:27 AM
This revision now requires changes to proceed.May 20 2020, 5:27 AM

Addressing comments

On the change itself, this does not seem to support interleaving.
I think I would rather try to go for a recursive helper function that takes ArrayRef slices and a leaf lambda but otherwise leaves GenericLoopNestBuilder untouched.
This should also evolve better when we have more loop types.

Modified this to not change the EDSC builders but added a Util struct that implements what is needed. PTAL

mravishankar marked an inline comment as done.May 23 2020, 1:11 AM
mravishankar added inline comments.
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
379

Can you give me more context here. I am not sure why I need to do that. I am just changing the class used. I dont follow why it is needed now, but wasnt there previously?

nicolasvasilache accepted this revision.May 26 2020, 2:51 AM

Thanks for the cleanup, looks nice!
I think you also have an opportunity to fix it completely by also taking the iterator types into account with 3-5 more locs (and a test).
Approving conditioned on that.

mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
379

I do not remember the chronology of when lowering to loops and the permutation argument was added to tiling but in the same way you are fixing the fact that not all loops are parallel after tiling, we also need to take the iterator types into account.

This also points at missing coverage in the test.

A few lines above we have:

if (!options.interchangeVector.empty())
  applyPermutationToVector(loopRanges, options.interchangeVector);

We should also have something along the lines of:

auto iteratorTypes = llvm::to_vector<4>(op.iterator_types().cast<ArrayAttr>().getValue());
if (!options.interchangeVector.empty())
  applyPermutationToVector(iteratorTypes, options.interchangeVector);

Could you please add a test that permutes and be sure that say your outer parallel loop becomes a sequential when appropriate?

mlir/lib/Dialect/Linalg/Utils/Utils.cpp
129

A few interspersed comments would be welcome on the fact that this recursive impl terminates and where it supports interleaved bands of loop types.

136

seems like we could have an isParallelAttr in the Utils.h and this would become xxx.take_while(isParallelAttr).

156

nice!

This revision is now accepted and ready to land.May 26 2020, 2:51 AM
mravishankar marked 7 inline comments as done.

Addressing comments, and adding a permutation test.

mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
379

Thanks for pointing this out. Added a test to verify the behavior as well.

Addressing comments.

This revision was automatically updated to reflect the committed changes.