[inductor] Defer memory operation lowering to wrapper #111402
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
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/111402
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 3c9fd63 with merge base 185e762 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
int3
added a commit
that referenced
this pull request
Oct 16, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. ghstack-source-id: 70aca600d57a98e99da85eef157fc37d4859008f Pull Request resolved: #111402
|
|
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]
int3
added a commit
that referenced
this pull request
Oct 17, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. ghstack-source-id: 2f238a47e43bc1ace75dde9863848b37108df34a Pull Request resolved: #111402
jansel
requested changes
Oct 17, 2023
torch/_inductor/codegen/wrapper.py
Outdated
Comment on lines
858
to
859
| name = buffer.get_name() | ||
| if name in self.freed: |
There was a problem hiding this comment.
Don't we need to do this on the last free, not the first one?
There was a problem hiding this comment.
sorry, not sure I understand this comment. What is the first/last free you're referring to here?
torch/_inductor/codegen/wrapper.py
Outdated
Comment on lines
858
to
859
| name = buffer.get_name() | ||
| if name in self.freed: |
There was a problem hiding this comment.
Don't we need to do this on the last free, not the first one?
torch/_inductor/codegen/wrapper.py
Outdated
Comment on lines
1534
to
1537
| name = buffer.get_name() | ||
| if name in self.freed: | ||
| return "" | ||
| self.freed.add(name) |
There was a problem hiding this comment.
can we avoid duplicate code with above?
There was a problem hiding this comment.
I've removed these entirely. I'm not sure why this change was introduced in your initial diff... but things seem to work regardless
|
This wasn't meant for review yet, that's why I marked it as a draft... should I be taking off the reviewers as well? This isn't the first time I've had a draft reviewed :/ |
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]
Closed
jansel
approved these changes
Oct 21, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]
int3
added a commit
that referenced
this pull request
Oct 24, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. ghstack-source-id: a7980e474d6d24e9e8aac84b6fa7b9250396d95a Pull Request resolved: #111402
|
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
andreigh
pushed a commit
to andreigh/pytorch
that referenced
this pull request
Oct 26, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. Pull Request resolved: pytorch#111402 Approved by: https://github.com/jansel
xuhancn
pushed a commit
to xuhancn/pytorch
that referenced
this pull request
Nov 7, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. Pull Request resolved: pytorch#111402 Approved by: https://github.com/jansel
Skylion007
pushed a commit
to Skylion007/pytorch
that referenced
this pull request
Nov 14, 2023
Right now, memory ops are being lowered to strings partly in scheduler.codegen() and partly in wrapper.codegen(). But that makes static memory planning (which is done entirely in `wrapper.codegen()`) difficult to implement as information is "lost" by that point. Pull Request resolved: pytorch#111402 Approved by: https://github.com/jansel
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.
Stack from ghstack (oldest at bottom):
Right now, memory ops are being lowered to strings partly in
scheduler.codegen() and partly in wrapper.codegen(). But that makes
static memory planning (which is done entirely in
wrapper.codegen())difficult to implement as information is "lost" by that point.
cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler