-
Notifications
You must be signed in to change notification settings - Fork 9
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
ODS integration #14
Comments
With #19 landed, there are now wrappers for MLIR operations that are nice to use. What's still lacking compared to other projects such as xDSL and Mojo is wrappers around types. I tried out some things and here are some thoughts I have. I would be interested in any comments or corrections on this. (cc: @mofeing @Pangoraw) Specifically, I was thinking to have each MLIR type be a concrete instance of an abstract MLIR struct ShapeType <: AbstractValue
value::MlirValue
function ShapeType(v::AbstractValue)
get_type(v) == parse(MLIRType, "!shape<shape>") || error("Expected ShapeType, got ", get_type(v))
return new(v.value)
end
end
struct Size <: AbstractValue
value::MlirValue
function Size(v::AbstractValue)
get_type(v) == parse(MLIRType, "!shape<size>") || error("Expected Size, got ", get_type(v))
return new(v.value)
end
end Since these particular types have mnemonics, it's clear what the assemblyformat looks like and verifications like above can be generated. Parametric TypesA lot of types are parametric, e.g. ( struct MemRef<element_type>
shape
layout
memory_space
end Builtin TypesAnother major annoyance is that a lot of builtin types don't have rich information in tablegen.
General ConstraintsIf we have a way to represent (all) MLIR types and attributes, we statically type those cases where operation arguments are constrained by a single type. However, often this is not the case and arguments are constrained by for example
I'm not sure how this could work in Julia. Interesting might be the IRDL dialect which is used to define new dialects at runtime. They also have a tblgen-to-irdl that's currently being developed further which could be useful as they're also trying to represent these constraints in IRDL automatically. |
My question here is: Are these generated types gonna implement some methods or some form of interface on the Julia side? I think we will be using MLIR types as objects to be passed, not as types of objects we build per se (but I might be wrong). So multiple dispatch wouldn't be needed. |
Yeah, what I wrote is missing some context. As part of my master thesis, I want to provide an easier way to generate MLIR using Julia constructs (this wouldn't necessarily be upstreamed here if it deviates too much from what others are thinking of). My current idea is to extend Pangoraw's Brutus example to support function definitions. Users could then write functions operating on MLIR Even without all that, I think the one advantage of representing LMK if you think I'm overlooking stuff or you disagree. I hope to have a more concrete implementation soon :) |
Ahh that's super cool! Like writing MLIR passes and lowerings in Julia? Then yes, it might make more sense to use parametric types. My concerns are related to runtime dispatch and overspecialization, but...
So... I'm ok with using parametric types. It will be also useful for checking traits of MLIR ops. |
The Python front-end has some amount of ODS integration,
https://github.com/llvm/llvm-project/blob/main/mlir/python/mlir/dialects/ArithOps.td
It would be nice if we could do that, without having to upstream our bindings...
The text was updated successfully, but these errors were encountered: