This is an archive of the discontinued LLVM Phabricator instance.

[mlir][vector] Fold scalar vector.extract of non-splat n-D constants
ClosedPublic

Authored by kuhar on Sep 12 2022, 6:33 PM.

Details

Summary

Add a new pattern to fold vector.extract over n-D constants that extract scalars.
The previous code handled ND splat constants only. The new pattern is conservative and does handle sub-vector constants.

This is to aid the arith::EmulateWideInt pass which emits a lot of 2-element vector constants.

Diff Detail

Event Timeline

kuhar created this revision.Sep 12 2022, 6:33 PM
Herald added a reviewer: aartbik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
kuhar requested review of this revision.Sep 12 2022, 6:33 PM

Thanks, @kuhar! LGTM. Just a few comments!

mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1575–1576

I think this condition is guaranteed by definition of the vector type.

1577–1578

Would it be too much work to also add support for n-D cases where a scalar is extracted? It would be very useful in general! Having it working for n-D would be great if it's just about adding some extra logic to compute the position. Supporting a sub-vector extraction would require more work that we can add in the future.

1587

I wonder if it would make sense to merge this pattern with the one above. They current share some code and when we eventually support n-D cases, the would be even more similar, except by the way the constant value is extracted, right?

kuhar marked an inline comment as done.Sep 13 2022, 8:07 AM
kuhar added inline comments.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1575–1576

Thanks, I wanted to exclude scalable vectors, but now I see I used the wrong predicate for this.

1577–1578

I considered this but was warned by @antiagainst to be careful not to blow up the size of the IR. Thinking about it more, I think this would be fine if the extracted element was a scalar instead of a nested vector constant, because we would always replace one vector.extract with one arith.constant with a single APInt/APFloat.

IE I think it would be safe to support n-D cases when all positions are provided, but not when some dims are still left. Does this make sense?

kuhar updated this revision to Diff 459753.Sep 13 2022, 8:10 AM
kuhar marked an inline comment as done.

Fixed scalable vector check

Mogball added inline comments.Sep 13 2022, 9:47 AM
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1570

Please match this using m_Constant. The defining op might be a different kind of constant op.

dcaballe added inline comments.Sep 13 2022, 12:18 PM
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1577–1578

IE I think it would be safe to support n-D cases when all positions are provided, but not when some dims are still left. Does this make sense?

Exactly! That's what I meant.

Regarding the sub-vector extraction, I'm not sure I understand the IR size concern. Could you please elaborate? This folding is something that will eventually happen in LLVM so I think the sooner we expose these constants the better.

kuhar added inline comments.Sep 13 2022, 12:43 PM
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1577–1578

Regarding the sub-vector extraction, I'm not sure I understand the IR size concern. Could you please elaborate? This folding is something that will eventually happen in LLVM so I think the sooner we expose these constants the better.

Say you have a large n-D constant vector: %v = arith.constant dence<...> : vector<...> and perform a series of extractions for sub-vectors.
If you encode it with vector.extract, each extraction needs < n * 64-bit positions. If you convert it to a series of constants, each representing some sub-vector, these constants may be much larger than the positions. I don't know if the in-memory attributes will be deduplicated or not, but this seems like something that can negatively affect the printing/parsing time in pathological cases.

kuhar updated this revision to Diff 459873.Sep 13 2022, 2:25 PM
kuhar marked an inline comment as done.

Handle n-D vectors. Match constants vectors.

kuhar retitled this revision from [mlir][vector] Fold vector.extract of non-splat 1D constants to [mlir][vector] Fold scalar vector.extract of non-splat n-D constants.Sep 13 2022, 2:27 PM
kuhar edited the summary of this revision. (Show Details)
kuhar marked an inline comment as done.
kuhar added inline comments.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1587

IMO the new pattern is sufficiently different that merging the two does not make the code cleaner.

dcaballe accepted this revision.Sep 13 2022, 2:39 PM

Thanks! LGTM

mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1577–1578

If you convert it to a series of constants, each representing some sub-vector, these constants may be much larger than the positions. I don't know if the in-memory attributes will be deduplicated or not, but this seems like something that can negatively affect the printing/parsing time in pathological cases.

It's ok for me if we don't want to support the sub-vector cases for now but I don't think making printing/parsing slower would justify not introducing that canonicalization. Actually, splitting a massive constant into smaller ones could even help. I would expect identical constants to be deduplicated. Again, I think this will happen in LLVM anyways.

This revision is now accepted and ready to land.Sep 13 2022, 2:39 PM
Mogball accepted this revision.Sep 13 2022, 4:45 PM
Mogball added inline comments.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1584

Can you drop a TODO to support other element types, like complex values?

kuhar updated this revision to Diff 459929.Sep 13 2022, 5:30 PM

Added a TODO to support more types. Rebased.

This revision was landed with ongoing or failed builds.Sep 13 2022, 5:31 PM
This revision was automatically updated to reflect the committed changes.