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

[WIP] IdModel-based inlining #2936

Closed
wants to merge 28 commits into from
Closed

[WIP] IdModel-based inlining #2936

wants to merge 28 commits into from

Conversation

naoyam
Copy link
Collaborator

@naoyam naoyam commented Sep 12, 2024

No description provided.

@naoyam
Copy link
Collaborator Author

naoyam commented Sep 12, 2024

!build --diff

1 similar comment
@naoyam
Copy link
Collaborator Author

naoyam commented Sep 13, 2024

!build --diff

@naoyam
Copy link
Collaborator Author

naoyam commented Sep 13, 2024

!build --diff-bench

@naoyam naoyam mentioned this pull request Sep 18, 2024
@naoyam naoyam mentioned this pull request Sep 18, 2024
@naoyam naoyam changed the base branch from main to irbfs_routines September 18, 2024 22:32
naoyam added a commit that referenced this pull request Sep 19, 2024
Encountered while working on #2936
naoyam added a commit that referenced this pull request Sep 19, 2024
Base automatically changed from irbfs_routines to main September 19, 2024 17:05
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.
@naoyam
Copy link
Collaborator Author

naoyam commented Sep 24, 2024

Closing as everything has been split up to smaller PRs.

@naoyam naoyam closed this Sep 24, 2024
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.

1 participant