-
Notifications
You must be signed in to change notification settings - Fork 52
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
[WIP] IdModel-based inlining #2936
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
!build --diff |
1 similar comment
!build --diff |
!build --diff-bench |
naoyam
force-pushed
the
idmodel_inlining
branch
from
September 18, 2024 21:06
d081929
to
d26924f
Compare
Merged
naoyam
added a commit
that referenced
this pull request
Sep 19, 2024
Encountered while working on #2936
The primary use case is when setting a loop domain of a tensor that would be involved in broadcast forwarding in the conventional inlining approach. For example, think of a fusion like below: t0 = [i0] t1 = [i0, i1] t2 = broadcast(t0, {false, true}); // [i0, b2] t3 = t1 + t2 To inline all tensors together, t0 and t2 would be inlined with broadcast forwarding. Suppose a loop domain of t3 would be set for all tensors, t0, for example, would have a loop domain of: {t0->axis(0), clone of t3->axis(1)}. In this case, however, the clone is almost an exact copy of the t3 ID, there's no use or def to define its exact mapping with the original t3 ID. This is problematic when inlining t0 since the inlining rule would use the Exact (or Broadcast) graph to determine the validity of inlining, but for the cloned ID of t0, since there's no def or use, it would have no mapping with any of the other IDs, which means the inlining would fail. The mapping option added in this PR workarounds the issue. While I am not completely confident about forcing certain ID mappings, I think it's a reasonable compromise between safety and flexibility. Besides, the mapping is currently only allowed if two IDs are the same per IterDomain::sameAs.
Closing as everything has been split up to smaller PRs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.