8000 Fix: specializing symbols after runtime assertions added cause codegen issue by laithsakka · Pull Request #153661 · pytorch/pytorch · GitHub
[go: up one dir, main page]

Skip to content

Fix: specializing symbols after runtime assertions added cause codegen issue #153661

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

Draft
wants to merge 7 commits into
base: gh/laithsakka/180/base
Choose a base branch
from

Conversation

laithsakka
Copy link
Contributor
@laithsakka laithsakka commented May 15, 2025

Stack from ghstack (oldest at bottom):

Fix #153650
Two things:

  1. input nodes that represents symbols that are used in runtime assertions should NOT be deleted. During remove_unused_inputs if the runtime assertions were inserted correctly and non missed this wont happpen.

  2. during codegen and runtime assertion insertion, do not apply the replacements to input nodes that represent symbols that are used in runtime assertions in order to avoid missing inserting runtime assertions depending on those symbols.
    and to prevent (in the case of inductor) generating invalid code.

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

Copy link
pytorch-bot bot commented May 15, 2025

🔗 Helpful Links

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

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

❌ 34 New Failures

As of commit 65e98aa with merge base 004dad4 (image):

NEW FAILURES - The following jobs have failed:

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

laithsakka added a commit that referenced this pull request May 15, 2025
@pytorch-bot pytorch-bot bot added ciflow/inductor release notes: fx release notes category labels May 15, 2025
@laithsakka laithsakka changed the title fix specialized symbols after runtime assertions added Fix: specializing symbols after runtime assertions added cause codegen issue May 15, 2025
r = self._find(s)

if only_specialized_backed and not (r.is_integer or r.is_real):
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we check not (r.is_integer or r.is_real)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if rhs is not integer, its guaranteed the input it still in the graph.
the replacement is not needed for the runtime assert symbol. it could be that its ok if we relax this,idk if we would hit issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually this should be int float and not is_integer, is_real

@laithsakka laithsakka marked this pull request as draft May 16, 2025 17:40
…ause codegen issue"


Fix #153650
if we have a runtime assertions u0+s1 =10
then s1 got specialized to say 8, then when s1 will no longer be part of the graph we shall replace it with 8. 

now here is an interesting situation, if we have assert(s0==10) and prefer runtime assertions over guards ! 
what should happen in that case? we do want the assertion to be emitted, meaning that specializing s0 
should not lead to s0 being removed from the graph. 
Maybe the proper fix is that we should NEVER remove symbols used in runtime assertions from the graph ever?



cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 16, 2025
…ause codegen issue"


Fix #153650
if we have a runtime assertions u0+s1 =10
then s1 got specialized to say 8, then when s1 will no longer be part of the graph we shall replace it with 8. 

now here is an interesting situation, if we have assert(s0==10) and prefer runtime assertions over guards ! 
what should happen in that case? we do want the assertion to be emitted, meaning that specializing s0 
should not lead to s0 being removed from the graph. 
Maybe the proper fix is that we should NEVER remove symbols used in runtime assertions from the graph ever?



cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 16, 2025
…ause codegen issue"


Fix #153650
if we have a runtime assertions u0+s1 =10
then s1 got specialized to say 8, then when s1 will no longer be part of the graph we shall replace it with 8. 

now here is an interesting situation, if we have assert(s0==10) and prefer runtime assertions over guards ! 
what should happen in that case? we do want the assertion to be emitted, meaning that specializing s0 
should not lead to s0 being removed from the graph. 
Maybe the proper fix is that we should NEVER remove symbols used in runtime assertions from the graph ever?



cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 17, 2025
@laithsakka
Copy link
Contributor Author

change the fix strategy trying the new one.

…ause codegen issue"


Fix #153650
Two things:
1) input nodes that represents symbols that are used in runtime assertions should NOT be deleted. 
2) during codegen and runtime assertion insertion, do not apply the replacements to input nodes that represent symbols that are used in runtime assertions.

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

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 17, 2025
…ause codegen issue"


Fix #153650
Two things:
1) input nodes that represents symbols that are used in runtime assertions should NOT be deleted. 
2) during codegen and runtime assertion insertion, do not apply the replacements to input nodes that represent symbols that are used in runtime assertions.

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

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 17, 2025
…ause codegen issue"


Fix #153650
Two things:
1) input nodes that represents symbols that are used in runtime assertions should NOT be deleted. During remove_unused_inputs if the runtime assertions were inserted correctly and non missed this wont happpen. 

2) during codegen and runtime assertion insertion, do not apply the replacements to input nodes that represent symbols that are used in runtime assertions in order to avoid missing inserting runtime assertions depending on those symbols.
and to prevent (in the case of inductor) generating invalid code.

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

[ghstack-poisoned]
laithsakka added a commit that referenced this pull request May 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0