-
Notifications
You must be signed in to change notification settings - Fork 15.5k
[mlir][arith] Refine the verifier for arith.constant #86178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -190,6 +190,14 @@ LogicalResult arith::ConstantOp::verify() { | |||||||
| return emitOpError( | ||||||||
| "value must be an integer, float, or elements attribute"); | ||||||||
| } | ||||||||
|
|
||||||||
| // Intializing scalable vectors with elements attribute is not supported | ||||||||
| // unless it's a vector splot. | ||||||||
| auto vecType = dyn_cast<VectorType>(type); | ||||||||
| auto val = dyn_cast<DenseElementsAttr>(getValue()); | ||||||||
| if ((vecType && val) && vecType.isScalable() && !val.isSplat()) | ||||||||
|
||||||||
| auto val = dyn_cast<DenseElementsAttr>(getValue()); | |
| if ((vecType && val) && vecType.isScalable() && !val.isSplat()) | |
| if (vecType && vecType.isScalable() && !isa<SplatElementsAttr>(getValue())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, have you thought of having a convenience type for scalable vectors? I mean ScalableVectorType that is VectorType with a classoff function that checks for the scalable bit, similar to how we have spirv::ScalarType that allows ints and floats. Then you could use that for isa<ScalableVectorType>(...) checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting idea - I've not thought about it, no. Thanks for the suggestion! Though isa<ScalableVectorType>(...) would be longer than vecType.isScalable() 🤷🏻
In general, we've been discussing how to better represent "scalable" vectors in MLIR for a while now. There was also a long discussion on "dynamic" vector type too:
I know that @dcaballe has been working on an updated class hierarchy for vectors. IIRC, that's not at the top of the priority list ATM, but it would be good to revisit it soon 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting idea - I've not thought about it, no. Thanks for the suggestion! Though isa(...) would be longer than vecType.isScalable() 🤷🏻
only if you have a vector type already. if the starting point is just Type, you could do auto scalableTy = dyn_cast<ScalableVectorType>(myType):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, we've been discussing how to better represent "scalable" vectors in MLIR for a while now. There was also a long discussion on "dynamic" vector type too:
What I suggested above is just a convenience type that doesn't affect the hierarchy in any way, similar to spirv::ScalarType or SplatElementsAttr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've not tried it yet, but intend to do so this week.
One worry that I have is naming - we may want to keep ScalableVectorType for when we do update the hierarchy. This is worth trying nonetheless!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be a good stepping stone but let's discuss further to make sure we don't make the potential big change more complicated. Revisiting VectorType is something I would like to do hopefully this month.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kuhar I went ahead and landed this to unblock myself elsewhere. I've also tried your suggestion and was positively surprised how straightforward that was:
@dcaballe I've prepared #87986 as one point in the discussion on VectorType refactor. Mainly so that we have a reference. However, having implemented it I feel that it would indeed be a good stepping stone 😅
Uh oh!
There was an error while loading. Please reload this page.