8000 use statically known true instead of guard size oblivious in bmm and mm inductor decompositions . by laithsakka · Pull Request #148893 · pytorch/pytorch · GitHub
[go: up one dir, main page]

Skip to content

use statically known true instead of guard size oblivious in bmm and mm inductor decompositions . #148893

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

Closed
wants to merge 4 commits into from

Conversation

laithsakka
Copy link
Contributor
@laithsakka laithsakka commented Mar 10, 2025

Stack from ghstack (oldest at bottom):

this was discussed with @eellison and he recommended using statically_known_true here, the intuition is. We already have 0/1 specializations in place, if we reach those checks with dynamic shapes that are not already specialized
then we do not want them to specialize them, "a recompilation here is not justified".
Those are all non-semantic changing optimizations.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @chenyang78 @kadeng @muchulee8 @amjames @chauhang @aakhundov

Copy link
pytorch-bot bot commented Mar 10, 2025

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/148893

Note: Links to docs will display an error until the docs builds have been completed.

✅ You can merge normally! (1 Unrelated Failure)

As of commit b68c0ef with merge base 0f8613b (image):

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

This comment was automatically generated by Dr. CI and updates every 15 minutes.

Copy link
Contributor
@eellison eellison left a comment

Choose a reason for hiding this comment

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

request review when tests are fixed

laithsakka added a commit that referenced this pull request Apr 21, 2025
@laithsakka laithsakka changed the title [DRAFT] use statically known true instead of guard size oblivous use statically known true instead of guard size oblivious Apr 21, 2025
@laithsakka laithsakka changed the title use statically known true instead of guard size oblivious use statically known true instead of guard size oblivious in bmm and mm decompositions . Apr 21, 2025
@laithsakka laithsakka added the topic: not user facing topic category label Apr 21, 2025
…in bmm and mm decompositions . "


this was discussed with eellison and he recommended using  statically_known_true here, the intuition is. We already have 0/1 specializations in place, if we reach those checks with dynamic shapes that are not already specialized 
then we do not want them to specialize them, "a recompilation here is not justified".
Those are all non-semantic changing optimizations.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx ipiszy chenyang78 kadeng muchulee8 amjames chauhang aakhundov

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request Apr 21, 2025
@laithsakka laithsakka changed the title use statically known true instead of guard size oblivious in bmm and mm decompositions . use statically known true instead of guard size oblivious in bmm and mm inductor decompositions . Apr 21, 2025
@laithsakka laithsakka requested a review from eellison April 21, 2025 22:23
Divigroup-RAP pushed a commit to Divigroup-RAP/PYTORCH that referenced this pull request Apr 22, 2025
@laithsakka laithsakka requested a review from bobrenjc93 April 22, 2025 17:12
Copy link
Contributor
@eellison eellison left a comment

Choose a reason for hiding this comment

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

I'm a little worried this will regress performance in gpt-fast, but, I agree that today this is not the best experience.

Getting these firing will be a nice end result of @bobrenjc93's work

@laithsakka
Copy link
Contributor Author
laithsakka commented Apr 25, 2025

We can always go back to guard_or_false if this end up being a regression @eellison

@laithsakka
Copy link
Contributor Author

@pytorchbot merge

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Apr 25, 2025
@pytorchmergebot
Copy link
Collaborator

Merge started

Your 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

Advanced Debugging
Check the merge workflow status
here

@pytorchmergebot
Copy link
Collaborator

The merge job was canceled or timed out. This most often happen if two merge requests were issued for the same PR, or if merge job was waiting for more than 6 hours for tests to finish. In later case, please do not hesitate to reissue the merge command
For more information see pytorch-bot wiki.

@laithsakka
Copy link
Contributor Author

@pytorchbot merge -f "GH is broken"

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged immediately since you used the force (-f) flag, bypassing any CI checks (ETA: 1-5 minutes). Please use -f as last resort and instead consider -i/--ignore-current to continue the merge ignoring current failures. This will allow currently pending tests to finish and report signal before the merge.

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0