-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[inductor] added a config to always add tensor constants #110491
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
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/110491
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (2 Unrelated Failures)As of commit 4007e1e with merge base e8f1f4e ( UNSTABLE - The following jobs failed but were likely due to flakiness present on trunk and has been marked as unstable:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This pull request was exported from Phabricator. Differential Revision: D49895154 |
torch/_inductor/graph.py
Outdated
name = f"constant_{name}" | ||
# We may generate a var name for each constant in the codegen. | ||
# Let's only keep sane characters. | ||
name = re.sub(r"[^a-zA-Z0-9_]", "_", name) |
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.
Where are the non-indent chars coming from? Could this result in name collisions?
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 special chars come from the model. For example, some model that we are dealing with has a bias named like this abc:XYZ
, where :
is not allowed in a var name in C/C++.
Very good point regarding the name collisions! Yes, I think we could have name collisions, although the chance might be low. Perhaps we could add a counter suffix to make a unique name? e.g.
name = re.sub(r"[^a-zA-Z0-9_]", "_", name)
name = f"{name}_{next(self.constant_id)"
What do you think? Thanks.
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 generated code and doesn't bleed into how we should store weights for weight refresh (which is presumably the unmodified original name as a string). Do any users need to reference the these generated names (which which case adding a suffix should be a last resort in case of duplicates, and track previously seen names), if it's just for readability during debug then adding the suffix doesn't appear to have much if any downside.
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 add a suffix and also check for collision.
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.
I don't think the user needs to reference the generated names.
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 add a suffix and also check for collision.
Done. Thanks.
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 use while
for adding suffix and checking.
Something like:
prefix = re.sub(r"[^a-zA-Z0-9_]", "_", name)
name = prefix
cnt = 0
while name in self.constants:
name = f"{prefix}_{cnt}"
cnt += 1
In this way the name is more tracible to the original model, since it's easy to see integers appended to some variable for un-named vars (is add_0
a constant or the result of some add operation?)
Also, I don't really need to assert
if our artificial name collides, we could just create a new one instead.
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.
Good point! Fixed. Thanks.
7f4aeb1
to
3948190
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
) Summary: In some scenarios, we want to update constants at runtime. In such cases, we have to keep the original constants in the generated code without applying any constant-inlining optimizations. This PR adds a config to force us to add tensor constants. Reviewed By: muchulee8 Differential Revision: D49895154
3948190
to
dc6bbb3
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
dc6bbb3
to
3d88cc3
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
) Summary: In some scenarios, we want to update constants at runtime. In such cases, we have to keep the original constants in the generated code without applying any constant-inlining optimizations. This PR adds a config to force us to add tensor constants. Reviewed By: muchulee8 Differential Revision: D49895154
This pull request was exported from Phabricator. Differential Revision: D49895154 |
dae0315
to
cb396b5
Compare
7207a4c
to
dae0315
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
This pull request was exported from Phabricator. Differential Revision: D49895154 |
cb396b5
to
857b323
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
) Summary: In some scenarios, we want to update constants at runtime. In such cases, we have to keep the original constants in the generated code without applying any constant-inlining optimizations. This PR adds a config to force us to add tensor constants. Reviewed By: muchulee8 Differential Revision: D49895154
857b323
to
ab03192
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
) Summary: In some scenarios, we want to update constants at runtime. In such cases, we have to keep the original constants in the generated code without applying any constant-inlining optimizations. This PR adds a config to force us to add tensor constants. Reviewed By: muchulee8 Differential Revision: D49895154
ab03192
to
bcad8e3
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
bcad8e3
to
4007e1e
Compare
This pull request was exported from Phabricator. Differential Revision: D49895154 |
@pytorchbot merge (Initiating merge automatically since Phabricator Diff has merged) |
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 |
Summary:
In some scenarios, we want to update constants at runtime.
In such cases, we have to keep the original constants in
the generated code without applying any constant-inlining
optimizations.
This PR adds a config to force us to add tensor constants.
Differential Revision: D49895154
cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @kadeng @muchulee8 @aakhundov @ColinPeppler