If you have i0 = i1 * 12, perform this replacement directly

[ezyang]

Stack from ghstack (oldest at bottom):

• -> If you have i0 = i1 * 12, perform this replacement directly #112653

In #112156 I added support for creating replacements on unbacked SymInts, so if you asserted that i0 == s0, we would replace i0 with s0 (only ever replacing unbacked with backed.)

However, if we have assertions involving only unbacked SymInts, we can also replace in this case! E.g., i0 == i1 or i0 == i1 * 12. The previous logic for generating replacements would reject these cases, because you're not allowed to replace unbacked with unbacked. Modifying the logic is not so easy though; ordinarily, we decide what substitution to prioritize by trying to replace the largest hinted symbol, but for unbacked integers we don't have this. To get around this problem, for now I only setup replacements for trivial symbol equals something else situations. Check the diff with whitespace ignored, the addition is quite small.

Signed-off-by: Edward Z. Yang ezyang@meta.com

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

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 afd7f3e with merge base 68dead4 ():

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

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

• inductor / cuda12.1-py3.10-gcc9-sm86 / test (aot_inductor_huggingface, 1, 1, linux.g5.4xlarge.nvidia.gpu) (gh)
• inductor / cuda12.1-py3.10-gcc9-sm86 / test (aot_inductor_torchbench, 1, 1, linux.g5.4xlarge.nvidia.gpu) (gh)

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

[ezyang]

cc @asmeurer

[asmeurer]

I guess this is related to #112347 (comment)

I'm still learning how this code works, so it's hard to comment too much here. Is it really a good idea to replace in both directions? That means you don't have to be careful about a == b being different from b == a, but maybe it's also possible for this to result in replacements that go backwards from what you wanted?

(again, hard for me to know the answers to these questions because I'm still learning my way around all this)

[ezyang]

Yeah, this simplification arose as desirable because we were trying to rewrite an integer so that it would pass through modulus checks.

Is it really a good idea to replace in both directions? That means you don't have to be careful about a == b being different from b == a, but maybe it's also possible for this to result in replacements that go backwards from what you wanted?

It's fine, for the equality replacements we are doing unification, so it doesn't matter which variable you end up with in the end, they're all in the same equivalence class.

(again, hard for me to know the answers to these questions because I'm still learning my way around all this)

Feel free to ask anything you need :)

[aakhundov]

This, together with the divisible_by workaround suggested in #112347, seems to help going through the reshape with -1 in the target shape in the internal model. Thanks!

[ezyang]

@pytorchbot merge

[pytorchmergebot]

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