This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Vector] Support 0-D vectors in ShuffleOp
ClosedPublic

Authored by nicolasvasilache on Dec 14 2021, 10:24 AM.

Details

Summary

Co-authored-by: Michal Terepeta <michalt@google.com>

Reviewed-by: nicolasvasilache

Diff Detail

Event Timeline

michalt created this revision.Dec 14 2021, 10:24 AM
michalt requested review of this revision.Dec 14 2021, 10:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 14 2021, 10:24 AM
nicolasvasilache accepted this revision.Aug 26 2022, 3:58 AM
This revision is now accepted and ready to land.Aug 26 2022, 3:58 AM
nicolasvasilache commandeered this revision.Aug 26 2022, 4:09 AM
nicolasvasilache edited reviewers, added: michalt; removed: nicolasvasilache.
This revision now requires review to proceed.Aug 26 2022, 4:09 AM
nicolasvasilache edited the summary of this revision. (Show Details)

Rebase.

Fix bugs and add canonicalization attern.

qcolombet accepted this revision.Aug 26 2022, 10:10 AM

LGTM

mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
599

Food for thoughts: Right now we don't allow mixing 0-D with 1-D, but I wonder if we should.
I am happy with limiting that for now. We can change this when/if the time comes.

This revision is now accepted and ready to land.Aug 26 2022, 10:10 AM
dcaballe accepted this revision.Aug 26 2022, 1:29 PM

The changes LGTM.

Still trying to make my mind around the benefits of having a 0d vector vs canonicalizing it to a 1d vector or a scalar. I have the impression that having a 0d vector is the result of leaking high-level concepts that belong to frameworks into the lower level layers of the compiler. Anyways, this is not the place to discuss that.

mlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir
427

nit: minor indentation and variable naming fixes for consistency.

Still trying to make my mind around the benefits of having a 0d vector vs canonicalizing it to a 1d vector or a scalar. I have the impression that having a 0d vector is the result of leaking high-level concepts that belong to frameworks into the lower level layers of the compiler. Anyways, this is not the place to discuss that.

When they appear, it is quite unnatural to use either vector<1xf32> or f32; either of these decisions severely leak corner cases all around; vector<f32> is significantly better from that perspective.
"Some" HW also have a notion of "vector FUs" and "scalar FUs" where crossing the vector / scalar can be extremely expensive.

The merits of 0-d have also been discussed independently: https://discourse.llvm.org/t/should-we-have-0-d-vectors/3097

The concept to look out as a red flag of leaks from above for is shapes containing 0x in them; that is another discussion.

nicolasvasilache marked 2 inline comments as done.Aug 27 2022, 3:46 AM
nicolasvasilache added inline comments.
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
599

Yes, this is not set in stone, if evidence show we should we can evolve it.

nicolasvasilache marked an inline comment as done.

Address comment.

This revision was landed with ongoing or failed builds.Aug 29 2022, 12:40 AM
This revision was automatically updated to reflect the committed changes.