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

feat[next]: Improve fieldop fusion #1764

Merged
merged 234 commits into from
Feb 6, 2025

Conversation

tehrengruber
Copy link
Contributor

@tehrengruber tehrengruber commented Dec 2, 2024

  • Add support for inlining into scans.
  • Fuse make_tuple(as_fieldop(...), as_fieldop(...)) calls into as_fieldop(λ(...) → make_tuple(...))(...).
  • Refactor pass such that inlining decision is expressed in a dedicated function _arg_inline_predicate.
  • Inline all let vars with dtype list.
  • Performance improvement: Stop visiting when reaching a stencil.
  • Bugfix for inlining of as_fieldop args that use the same arg twice, e.g. as_fieldop(...)(a, b).
  • Bugfix such that only expressions inside the expr of an itir.SetAt are considered.

@tehrengruber tehrengruber marked this pull request as ready for review January 16, 2025 11:20
@tehrengruber tehrengruber requested a review from havogt January 16, 2025 11:28
@@ -119,9 +175,7 @@ def fuse_as_fieldop(
pass
elif cpm.is_call_to(arg, "if_"):
Copy link
Contributor

Choose a reason for hiding this comment

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

I was going through the whole file again and got stuck here. Can we briefly discuss

  • if it makes the code cleaner, if instead of building an applied field_op we extract the stencil_body and args
  • instead of special casing for if we support any function (because only if should be marked as eligible, but if we change the algorithm to mark eligible, we should not have to touch this line)

target=node.target,
)

def visit_FunCall(self, node: itir.FunCall, **kwargs):
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's rewrite the whole thing together for 2 reasons:

  • knowledge sharing
  • after it is now (maybe) correct, focus on readability.

@havogt
Copy link
Contributor

havogt commented Jan 20, 2025

Can we generate a complicated IR (which we also can easily maintain) as a performance regression test?

Copy link
Contributor

@havogt havogt left a comment

Choose a reason for hiding this comment

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

looks good for now. as discussed, it would be good to spend time later to improve interoperability of transformations.

@tehrengruber
Copy link
Contributor Author

tehrengruber commented Feb 6, 2025

Can we generate a complicated IR (which we also can easily maintain) as a performance regression test?

I will create this as soon as we have the performance dashboard and I have some spare minutes.

@tehrengruber tehrengruber merged commit d916ae5 into GridTools:main Feb 6, 2025
22 of 23 checks passed
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.

4 participants