Skip to content
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

Merged
merged 9 commits into from
Nov 13, 2023
Merged

AIE Python Bindings #716

merged 9 commits into from
Nov 13, 2023

Conversation

AndraBisca
Copy link
Collaborator

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

Copy link
Contributor

@makslevental makslevental left a 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

  1. 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);
  2. Shortly they will support infix operators [mlir][python] value casting llvm/llvm-project#69644;
  3. My next upstream PR will be region_op.



# Create an aie device on specified target architecture.
class Device(DeviceOp):
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

@makslevental makslevental Nov 6, 2023

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).

Copy link
Contributor

@makslevental makslevental Nov 7, 2023

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.

python/dialects/_AIE_util.py Outdated Show resolved Hide resolved
@fifield
Copy link
Collaborator

fifield commented Nov 3, 2023

In general I think this isn't the right thing to do because

  1. 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);
  2. Shortly they will support infix operators [mlir][python] value casting llvm/llvm-project#69644;
  3. My next upstream PR will be region_op.

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?

@makslevental
Copy link
Contributor

makslevental commented Nov 3, 2023

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.

@makslevental
Copy link
Contributor

@fifield where are these examples? Can you link so I can see how they're written?

@jgmelber
Copy link
Collaborator

jgmelber commented Nov 3, 2023

@makslevental this is representative of the style in the examples: test/python/codeRegion.py

@makslevental
Copy link
Contributor

makslevental commented Nov 3, 2023

@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.

@AndraBisca
Copy link
Collaborator Author

AndraBisca commented Nov 6, 2023

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

@makslevental makslevental reopened this Nov 6, 2023
@makslevental
Copy link
Contributor

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.

@makslevental makslevental self-requested a review November 6, 2023 16:58
@AndraBisca
Copy link
Collaborator Author

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!

@stephenneuendorffer
Copy link
Collaborator

Sounds good! I will still inquire more about the deadlines, because we might be able to wait(?). I'll let you know!

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?

@makslevental
Copy link
Contributor

makslevental commented Nov 7, 2023

we need to make sure we can get up to HEAD

my contribution: #724 :)

@AndraBisca
Copy link
Collaborator Author

Sounds good! I will still inquire more about the deadlines, because we might be able to wait(?). I'll let you know!

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?

Yes, I can do that!

@makslevental
Copy link
Contributor

makslevental commented Nov 7, 2023

image

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

  1. And transition to using value builders instead of operation builders.

@AndraBisca AndraBisca marked this pull request as draft November 8, 2023 17:10
@jgmelber jgmelber self-requested a review November 13, 2023 22:12
Copy link
Collaborator

@jgmelber jgmelber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@makslevental makslevental marked this pull request as ready for review November 13, 2023 22:33
@makslevental makslevental merged commit cd86e0d into main Nov 13, 2023
6 checks passed
@makslevental makslevental deleted the python-bindings branch November 13, 2023 23:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants