-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[TIR][Schedule] enhance compute_at and reverse_compute_at primitive to choose possible position #12450
Conversation
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 except for one nit
Do you have ideas about the naming of |
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.
This is definitely a valid concern, while we might want to deliberate on the following two questions:
- Is it possible to generalize the boolean flag
to_early_stage
to an integer, and allow users to specify which produecr/consumer it should move to? - The naming
to_early_stage
itself is definitely a bit less informative. Let's consider a better name
Besides, given that we have reverse_compute_at
symmetrically, shall we also support a similar flag for it?
Thanks in advance!
Thanks @junrushao1994 I quite agree with your suggestion. Currently I modify it according to scenario we have encountered. Do you have any suggestion about the better name? |
Hi @junrushao1994 , what do you think of my follow suggestion?
The above rules apply to "reverse_compute_at" at same time Thanks in advance! |
2e4c30e
to
ff77782
Compare
@junrushao Hi, I have changed as you mentioned, could you please help review again? Thanks in advance! |
Hey sorry for the late reply! Happy to do another round of review tomorrow! |
@junrushao Hi, I don't receive any feedback information. Did I miss something? |
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 the continuous improvement!
python/tvm/tir/schedule/schedule.py
Outdated
The block index of the loop body subtree blocks | ||
-1 means inserted into the last possible insertion point | ||
-2 means inserted into the first possible insertion point |
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.
The block index of the loop body subtree blocks | |
-1 means inserted into the last possible insertion point | |
-2 means inserted into the first possible insertion point | |
The block index of the loop body subtree blocks: | |
- `index = -1` means inserted into the last possible insertion point; | |
- `index = -2` means inserted into the first possible insertion point; | |
- Otherwise, `index` is a nonnegative number that indicates the insertion point |
src/tir/schedule/primitive.h
Outdated
* \param index The block index of the loop body subtree blocks | ||
* -1 means inserted into the last possible insertion point | ||
* -2 means inserted into the first possible insertion point |
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.
Let's update the doc accordingly
// Step 4. Return the possible insertion point according to index | ||
int insert_position; | ||
if (index == -1) { | ||
insert_position = split.first_consumer_position; | ||
} else if (index == -2) { | ||
insert_position = split.last_producer_position + 1; | ||
} else if (index >= 0 && index >= split.last_producer_position + 1 && | ||
index <= split.first_consumer_position) { | ||
insert_position = index; | ||
} else { | ||
LOG(FATAL) << "Valid index:(-1, -2, [" << split.last_producer_position + 1 << ", " | ||
<< split.first_consumer_position << "]), " | ||
<< "current index=" << index; | ||
throw; | ||
} | ||
return insert_position; |
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.
Thanks for updating the logic here! It's much clearer now!
/*subtrees=*/AsArray(loop->body), | ||
/*producer_srefs=*/producer_srefs, | ||
/*consumer_srefs=*/consumer_srefs, /*block2realize=*/&block2realize); | ||
/*consumer_srefs=*/consumer_srefs, /*block2realize=*/&block2realize, | ||
/*index*/ index); |
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.
/*index*/ index); | |
/*index=*/index); |
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.
Thanks @yincs-intellif for the update! The diff is in a pretty good shape now! Let's fix some final nitpicks and then get it merged!
…o choose possible position
Hi @junrushao @Hzfengsy The final modification has been updated. |
Thanks @yincs-intellif for this PR and continuous update. |
…o choose possible position (apache#12450) Current TIR "compute_at" primitive will compute at it's closest consumers. When a block has multiple producers, whoever compute at later who is behind. But for some special hardware, we usually hope keep the a certain order whatever it's compute at early or late. eg: block A and block B are producers of block C. block A compute at block C first and block B compute at block C later. We hope the result is block B->block A->block C under some loop var.
Current TIR "compute_at" primitive will compute at it's closest consumers. When a block has multiple producers, whoever
compute at later who is behind. But for some special hardware, we usually hope keep the a certain order whatever it's compute at early or late.
eg: block A and block B are producers of block C. block A compute at block C first and block B compute at block C later. We hope the result is block B->block A->block C under some loop var.
cc @Hzfengsy @junrushao1994