-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[mlir][IR] Allow !llvm.ptr
as vector element type
#125690
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 all commits
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 |
---|---|---|
|
@@ -40,6 +40,11 @@ def ValueSemantics : NativeTypeTrait<"ValueSemantics"> { | |
let cppNamespace = "::mlir"; | ||
} | ||
|
||
/// Type trait indicating that the type is a pointer-like type. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would deserve a bit more documentation: what's the implication of marking a type with "pointer-like"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note: we wouldn't have to answer this kind of difficult question if we were making (Please take this comment thread as a current blocker) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if we rename it to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think that's addressing my underlying concern: anything that isn't named "vectorElementTypeInterface" or something like this should be a separate PR that we can reason about on its own merits. The fundamental problem here is that there is nothing special about pointers for vector element types from a builtin type point of view, I don't quite see a workaround to this right now TBH. |
||
def PointerLike : NativeTypeTrait<"PointerLike"> { | ||
let cppNamespace = "::mlir"; | ||
} | ||
|
||
//===----------------------------------------------------------------------===// | ||
// ComplexType | ||
//===----------------------------------------------------------------------===// | ||
|
@@ -1249,7 +1254,12 @@ def Builtin_UnrankedTensor : Builtin_Type<"UnrankedTensor", "unranked_tensor", [ | |
// VectorType | ||
//===----------------------------------------------------------------------===// | ||
|
||
def Builtin_VectorTypeElementType : AnyTypeOf<[AnyInteger, Index, AnyFloat]> { | ||
// Note: VectorType supports pointer-like types as element types. Examples for | ||
// pointer-like types are !llvm.ptr and !ptr.ptr. This makes the MLIR vector | ||
// type design symmetric to the LLVM vector type. That's desirable because the | ||
// MLIR vector type is used in the LLVM dialect. | ||
def Builtin_VectorTypeElementType | ||
: AnyTypeOf<[AnyInteger, Index, AnyFloat, AnyPointerLike]> { | ||
let cppFunctionName = "isValidVectorTypeElementType"; | ||
} | ||
|
||
|
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 wonder if this should be an interface... we may have common methods to retrieve the address space, at least?
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.
As long as there are no interface methods that we would like to add (now or in the future), I would leave it as a trait.
Uh oh!
There was an error while loading. Please reload this page.
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'm not sure there's demand upstream for an interface, but querying the memory space and perhaps whether the pointer is opaque could be useful for downstream. Maybe CIR and flang folks might have a use.
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.
Given that changing this to an interface is not really intrusive, I vote in favor of adding this once a use case pops up.
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.
Yes, that's what I was thinking but I'm also ok with adding this on a case by case basis.