This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Move `expand-atomic` to test passes. Enable the pattern in Std2LLVM rewrite.
AbandonedPublic

Authored by pifon2a on Nov 4 2020, 12:27 PM.

Details

Summary

This is consistent with the patterns in ExpandTanh.cpp and
ExpandMemRefReshape.cpp. The application of this pattern should happen in
StandardToLLVM lowering not in a separate pass.

Diff Detail

Event Timeline

pifon2a created this revision.Nov 4 2020, 12:27 PM
pifon2a requested review of this revision.Nov 4 2020, 12:27 PM
pifon2a updated this revision to Diff 302938.Nov 4 2020, 12:29 PM

Fix comments.

ftynse added a comment.Nov 5 2020, 1:35 AM

I'm not convinced about this one. I have not reviewed https://reviews.llvm.org/D90235 that added the memref reshape expansion, and I would have complained about that too. TanhExpansion doesn't seem to be plugged by default in the lowering.

My concerns are:

  • This increases the complexity of the std-to-llvm conversion, making it also apply some std-to-std patterns. (At some point, we actually had a direct conversion from std to LLVM IR, but decided to add the LLVM dialect to make conversion more progressive.) It's unclear where to draw the line on adding such patterns: we will also include the ceildiv/floordiv expansion proposed in another review thread, we could also need the expansion of pointwise tensor operations into loops, then cfg (be they std.addf on tensor operands, or the new operation being discussed on the forum), and so on, further increasing complexity. At the same time, std-to-llvm conversion is already big and complex enough, with StandardToLLVM.cpp being the second largest file in LoC after StandardDialect/Ops.cpp in the codebase...
  • I can imagine users that only want the conversion and prefer to handle expansions differently, by targeting LLVM intrinsics or specific instructions if they go to lower levels without leaving MLIR. Different platforms may support different atomics. This was the argument for keeping tanh expansion outside the conversion to LLVM as far as I recall.
  • The layering looks weird in https://reviews.llvm.org/D90235, with added dependency on from StdToLLVMConversion on StdTransforms. These things look like they should be independent.

I think I would be in favor of some expansion pass (just don't call it -std-to-std!) that eliminates operations we don't want to see at the entry of the conversion pass, similarly to the pass we have that prepares the LLVM dialect for translation to LLVM IR because the dialect is slightly more relaxed. While this increases the complexity of the pipeline by having one extra pass, the decrease in complexity and semantic load of each pass largely compensates that IMO.

mlir/test/lib/Transforms/TestExpandAtomic.cpp
1

Not: the description is copy-pasta

I can imagine users that only want the conversion and prefer to handle expansions differently, by targeting LLVM intrinsics or specific instructions if they go to lower levels without leaving MLIR. Different platforms may support different atomics. This was the argument for keeping tanh expansion outside the conversion to LLVM as far as I recall.

ExpandMemRefReshape and ExpandAtomic differ from ExpandTanh, because they exist only for code reuse, without them MemRefReshapeOp and AtomicRMWOp are impossible to lower to LLVM for all "flavors".

I propose the following: I will remove`populateExpand[Atomic|MemRefReshape]patterns` from StandardToLLVM.cpp, but still leave TestExpandAtomic, TestExpandMemRefReshape in mlir/test/Transforms. Then the users can add these patterns to their LLVM lowering pass if needed, or a combination of these passes to their custom "std2std" pass

ftynse added a comment.Nov 9 2020, 5:24 AM

I propose the following: I will remove`populateExpand[Atomic|MemRefReshape]patterns` from StandardToLLVM.cpp, but still leave TestExpandAtomic, TestExpandMemRefReshape in mlir/test/Transforms. Then the users can add these patterns to their LLVM lowering pass if needed, or a combination of these passes to their custom "std2std" pass

What would be the default in-tree way of doing this? We wouldn't expect people to run -test-expand-atomic -convert-std-to-llvm or having to write a custom pass every time they need it, hence my suggestion of an additional "legalization" pass.