-
Notifications
You must be signed in to change notification settings - Fork 83
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
dialects: Enable bufferized stencil.apply #2982
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2982 +/- ##
==========================================
- Coverage 89.86% 89.85% -0.01%
==========================================
Files 409 409
Lines 51171 51217 +46
Branches 7939 7951 +12
==========================================
+ Hits 45985 46023 +38
- Misses 3925 3931 +6
- Partials 1261 1263 +2 ☔ View full report in Codecov by Sentry. |
if self.dest: | ||
printer.print_list(self.dest, print_destination_operand) | ||
else: | ||
printer.print_list((r.type for r in self.res), printer.print_attribute) |
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.
Not so keen on this syntax, if I'm understanding correctly that it hides that the bufferized version does not actually have a SSA return value.
Also, can you not have dest+res in the unbufferized mode?
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 went with apply only able to be fully value-semantic (having results in res) or reference-semantics (having destinations in dest), never a mix of both
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 could clarify that in a docstring I guess
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.
My point was something else, that dest is printed after the ->
(which unhelpfully isn't shown in the 4-line snippet above but comes just before)
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.
Okay, would you happen to have a proposed syntax then? I just went with the easiest to switch to here, and have no strong opinion for that one
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.
To keep it simple, you could have -> ( ... )
for results and dest( .... )
or outs(....)
for the destination-style passing.
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 could also consider re-using print_assign_argument
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.
Done with outs, WDYT?
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, thanks for this
if self.dest: | ||
printer.print_list(self.dest, print_destination_operand) | ||
else: | ||
printer.print_list((r.type for r in self.res), printer.print_attribute) |
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, thanks for this
To match #2982 --------- Co-authored-by: n-io <n-io@users.noreply.github.com>
I.e., make stencil.apply able to express computations on reference-semantic fields through destination operands, instead of only value-semantic through results.