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

dialects: (transform) Fix amount of returned loops in TileOp #3080

Merged
merged 9 commits into from
Aug 26, 2024

Conversation

JonasCrols
Copy link
Contributor

This PR fixes a bug where, when an array contains zeros, unneccessary loops are created. the total amount of return loops should be equal to the amount of non zero values

@JonasCrols
Copy link
Contributor Author

@superlopuh @jorendumoulin

len(static_sizes.as_tuple())
if isinstance(static_sizes, DenseArrayBase)
else 0
self.amount_of_non_zero_sizes(static_sizes, dynamic_sizes)
Copy link
Member

Choose a reason for hiding this comment

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

Why this name? Is it from MLIR?

Copy link
Member

Choose a reason for hiding this comment

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

I ask this because our usual convention would make this num_non_zero_sizes), but if MLIR calls it this way then we can follow their convention, as long as we add a link to their implementation.

Copy link
Member

Choose a reason for hiding this comment

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

BTW this implementation is a little surprising, could you please document the logic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, sorry for the delayed answer. In MLIR this isn't computed using specific helper function at all. rather they use the count-function to reach this goal.
unsigned numExpectedLoops = staticTileSizes.size() - llvm::count(staticTileSizes, 0);
As xDSL does not have any such function. I implemented this helper function myself directly. is it better to keep the logic the same as in MLIR? of coarse I can use the count function on the Array as Tuple

Copy link
Member

Choose a reason for hiding this comment

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

That's interesting, why not replicate this logic? It seems to not use the dynamic sizes, which makes sense to me, as we can't really reason about them. The Python spelling of this function would be:
len(static_sizes) - static_sizes.count(0), which is quite different from the implementation you propose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i see what you're saying, fixed it!

Copy link

codecov bot commented Aug 21, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.89%. Comparing base (c5c77e2) to head (66c8e1f).
Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3080   +/-   ##
=======================================
  Coverage   89.89%   89.89%           
=======================================
  Files         417      417           
  Lines       52948    52953    +5     
  Branches     8215     8215           
=======================================
+ Hits        47597    47602    +5     
  Misses       4022     4022           
  Partials     1329     1329           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@superlopuh superlopuh added the dialects Changes on the dialects label Aug 23, 2024
@jorendumoulin jorendumoulin merged commit ee743a2 into xdslproject:main Aug 26, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialects Changes on the dialects
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants