This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg][conv] Flatten the channel dimension
AbandonedPublic

Authored by awarzynski on Apr 25 2023, 7:08 AM.

Details

Summary

This patch adds an option to flatten the channel dimension when
vectorising 1D convolutions. This is very beneficial when vectorising
convolutions of tensors with low channel count (e.g. 1 or 2). Tensors
like this are very common in Computer Vision workloads.

This doesn't change the vectorisation in any fundamental way. However,
it does require collapsing and then re-expanding shapes as well as some
other fine-tuning when enabled. At the Linalg vectoriser level, this is
controlled through the flattenChannelDim flag (new parameter for
depthwiseConv), which defaults to false (so that the default
behaviour does not change).

Co-authored by: Bradley Smith <bradley.smith@arm.com>

Diff Detail

Event Timeline

awarzynski created this revision.Apr 25 2023, 7:08 AM
Herald added a project: Restricted Project. · View Herald Transcript
awarzynski requested review of this revision.Apr 25 2023, 7:08 AM

Hi everyone,

This specialization of the vectorizer is incredibly beneficial for our workloads. I do realize that there's a bit of code duplication here, so I am happy to refactor this if there's a better way. I am yet to figure out how to connect flattenChannelDim (in Vectorization.cpp) to the vectorization patters, but was hoping the get some feedback on the changes in depthwiseConv first. I hope that that's OK.

Thanks for taking a look!

awarzynski retitled this revision from [linalg][conv] Flatten the channel dimension to [mlir][linalg][conv] Flatten the channel dimension.Apr 26 2023, 12:51 AM

Thanks for the contribution! I think the general consensus here is that we have to refactor all the "pre-vectorization" convolution decomposition/transformation work somewhere outside the vectorizer but we haven't had a chance to do so. I would be reluctant to adding more complexity to Vectorization.cpp in this regard without at least trying to do so (to the extent that I have a patch that introduces masking support for convolutions but I'm stuck with it for the same reason). Since your flatten transformation seems something relatively independent of the existing decomposition, would you be willing to try moving it to a pre-vectorization pass? Thanks!

Thanks for the contribution! I think the general consensus here is that we have to refactor all the "pre-vectorization" convolution decomposition/transformation work somewhere outside the vectorizer but we haven't had a chance to do so. I would be reluctant to adding more complexity to Vectorization.cpp in this regard without at least trying to do so (to the extent that I have a patch that introduces masking support for convolutions but I'm stuck with it for the same reason). Since your flatten transformation seems something relatively independent of the existing decomposition, would you be willing to try moving it to a pre-vectorization pass? Thanks!

+1, this seems like you'd want to reach for a pre-vectorization rewrite at the tensor level.

Thanks for the contribution! I think the general consensus here is that we have to refactor all the "pre-vectorization" convolution decomposition/transformation work somewhere outside the vectorizer but we haven't had a chance to do so. I would be reluctant to adding more complexity to Vectorization.cpp in this regard without at least trying to do so (to the extent that I have a patch that introduces masking support for convolutions but I'm stuck with it for the same reason). Since your flatten transformation seems something relatively independent of the existing decomposition, would you be willing to try moving it to a pre-vectorization pass? Thanks!

+1, this seems like you'd want to reach for a pre-vectorization rewrite at the tensor level.

Thank you for taking a look and for your feedback! I'm worried that a pass won't be sufficient. Basically, I am trying to rewrite "depthwise NHWC" convolutions as "depthwise NH(WxC)" (or "depthwise NHW"). Now, the vectorizer splits convolutions into:

  1. "channeled with batch number" (see here) (e.g. depthwhise NHWC),
  2. "non-channeled without batch number" (see here) (e.g. "plain" HW).

However, what I am proposing would require a dedicated category:

  1. "non-channeled with batch number" (e.g. "depthwise NHW").

So, on top of a pass I will most likely need yet another hook/case in the vectorizer to support these "new" convolutions. Perhaps I'm missing something obvious? In any case, I wanted to bring this up before attempting a different approach (i.e. with a pass). If need be, would it be OK to introduce another case for convolutions in the vectorizer?

So, on top of a pass I will most likely need yet another hook/case in the vectorizer to support these "new" convolutions. Perhaps I'm missing something obvious? In any case, I wanted to bring this up before attempting a different approach (i.e. with a pass). If need be, would it be OK to introduce another case for convolutions in the vectorizer?

Yes, I think if you can move most of the transformation to a pre-vectorizer pass, then just adding a new case to drive the specific vectorization for that case would be acceptable.

awarzynski abandoned this revision.May 15 2023, 5:13 AM

So, on top of a pass I will most likely need yet another hook/case in the vectorizer to support these "new" convolutions. Perhaps I'm missing something obvious? In any case, I wanted to bring this up before attempting a different approach (i.e. with a pass). If need be, would it be OK to introduce another case for convolutions in the vectorizer?

Yes, I think if you can move most of the transformation to a pre-vectorizer pass, then just adding a new case to drive the specific vectorization for that case would be acceptable.

Thank you for confirming!

I agree that that would be much cleaner and more future-proof, though will require more work. Let me abandon this for now. My bandwidth is limited ATM, but we should be able to upload something in the next few months (indicating timescales just in case others are interested in this as well). Thank you for the feedback!