-
Notifications
You must be signed in to change notification settings - Fork 94
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
AIE Python Bindings #716
AIE Python Bindings #716
Conversation
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 I think this isn't the right thing to do because
- There are now value builders being generated automatically [mlir][python] generate value builders llvm/llvm-project#68308 (if you check in
_AIE_ops_gen.py
you will see them just under the conventional builders); - Shortly they will support infix operators [mlir][python] value casting llvm/llvm-project#69644;
- My next upstream PR will be
region_op
.
python/dialects/_AIE_syntax.py
Outdated
|
||
|
||
# Create an aie device on specified target architecture. | ||
class Device(DeviceOp): |
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.
This is going to break as soon as we bump due to this PR I landed upstream llvm/llvm-project#68853.
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.
Hey Maks, thank you for your detailed review! I looked through the PRs you mentioned above. Could you please help me understand why this would break exactly? In the PR above it looks like extensions that were calling super.init() can stay unchanged.
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.
You're missing the registration decorators register_operation(_Dialect, replace=True)
(like here). Also btw with this particular builder, you're better off just registering an attribute builder for AIEDevice
(same with all of these that are basically making attributes in the super
) or even better changing AIEDevice
to be an I32EnumAttr so that its attribute builder is free (see here).
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.
Sorry I didn't realize that AIEDevice
is already an EnumAttr
. So you can get this for free by signing up using GEN_ENUM_BINDINGS
.
We have a set of examples and tests using these bindings and we are maintaining them downstream. This is one in a set of PRs to get all that landed. Are these all things we can apply incrementally to what we have? |
You can just choose not to use it but it's all exactly the same functionality (and more). My only point is why have code you have to maintain when upstream is already maintaining the same code with the same functionality. |
@fifield where are these examples? Can you link so I can see how they're written? |
@makslevental this is representative of the style in the examples: test/python/codeRegion.py |
Plenty that can be "regularized" there. For example, you can already rewrite this to use just regular python for loops https://github.com/llvm/llvm-project/blob/main/mlir/test/python/dialects/scf.py#L64. |
I understand that what I have hand-implemented in this PR will become auto-generated in the near future. I look forward to that and will be ready to modify all of these examples accordingly. However, because of internal deadlines, our priority right now is to support all the downstream work that is currently using these simple sugar bindings. We should discuss internally how this aligns with the release of your automated python bindings, @makslevental |
Whoops finget slipped... Anyway of course that's reasonable. I was just trying to emphasize that some of those PRs are only a couple of days away from being merged. Anyway I'll just port this code here when they're merged. |
Sounds good! I will still inquire more about the deadlines, because we might be able to wait(?). I'll let you know! |
ade2e94
to
f3b7943
Compare
I think we really need to move to using the bindings that are upstream. There's no real value in diverging from that, as far as I can tell. I think in the short term, we need to make sure we can get up to HEAD and then propose a time frame to migrate the python bindings. @AndraBisca can you figure out a time frame for that? |
my contribution: #724 :) |
Yes, I can do that! |
This upstream PR has been merged: llvm/llvm-project#69644. I have been working on this feature for ~9 months 🎉. What this means is we can now transition to using infix operators for all operations (that we choose to implement for). The way this works is described in the PR but I'll recapitulate here: the only thing 1 we need to do is register a "value caster": @register_value_caster(F16Type.static_typeid)
@register_value_caster(F32Type.static_typeid)
@register_value_caster(F64Type.static_typeid)
@register_value_caster(IntegerType.static_typeid)
class ArithValue(Value):
__add__ = partialmethod(_binary_op, op="add")
__sub__ = partialmethod(_binary_op, op="sub")
__mul__ = partialmethod(_binary_op, op="mul") and upstream will take care of the rest: a = arith.constant(value=FloatAttr.get(f16_t, 42.42))
b = a + a
# CHECK: ArithValue(%0 = arith.addf %cst, %cst : f16)
print(b)
a = arith.constant(value=FloatAttr.get(f32_t, 42.42))
b = a - a
# CHECK: ArithValue(%1 = arith.subf %cst_0, %cst_0 : f32)
print(b)
a = arith.constant(value=FloatAttr.get(f64_t, 42.42))
b = a * a
# CHECK: ArithValue(%2 = arith.mulf %cst_1, %cst_1 : f64)
print(b) I'll plan to start rolling this out soon (this week) but it should be easy enough for anyone to jump in. Footnotes
|
55a80b9
to
c10abfd
Compare
0d889ad
to
ff0a808
Compare
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.
LGTM
This PR introduces an extension of the auto-generated python bindings we currently have in the repo. In particular, the extended operations have specialised constructors that can take in python integers as inputs. For now, only the most widely used operations in the AIE dialect have been extended. The others will be added in future PRs.
This PR relies on #715