Introduce constrain_range; remove old expr_subs#95063
Introduce constrain_range; remove old expr_subs#95063ezyang wants to merge 10 commits intogh/ezyang/1826/basefrom
Conversation
Signed-off-by: Edward Z. Yang <ezyang@meta.com> [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/95063
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 5185e15: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
Signed-off-by: Edward Z. Yang <ezyangmeta.com> [ghstack-poisoned]
This PR introduces a new `constrain_range` function which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard. The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work. Signed-off-by: Edward Z. Yang <ezyangmeta.com> [ghstack-poisoned]
This PR introduces a new `constrain_range` function which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard. The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work. Signed-off-by: Edward Z. Yang <ezyangmeta.com> [ghstack-poisoned]
This PR introduces a new `constrain_range` function which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard. The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work. Signed-off-by: Edward Z. Yang <ezyangmeta.com> [ghstack-poisoned]
eellison
left a comment
There was a problem hiding this comment.
Nice. We could start producing a range for Symints like .nonzero() at some point.
| if isinstance(expr, sympy.Integer): | ||
| return analysis.constant(int(expr), torch.int64) | ||
| elif isinstance(expr, sympy.Float): | ||
| elif isinstance(expr, sympy.Number): |
There was a problem hiding this comment.
what caused this change ?
There was a problem hiding this comment.
1/3 turns into a Rational which is not a float. There's something kind of fishy going on here... I am still feeling like I want to pass the sympy expressions directly to analysis.constant without casting it to float first.
| # are conservative: the int MUST fall in the range, but the | ||
| # range may contain ints which may not actually appear in | ||
| # practice | ||
| self.var_to_range: Dict["sympy.Symbol", ValueRanges] = {} |
There was a problem hiding this comment.
do we not have a similar range for SymFloats ? any reason to constrict ?
There was a problem hiding this comment.
It just didn't seem necessary! Also, I view the range analysis on floats as a sort of necessary evil when users do naughty things like sqrt, and for the most part, I only really want to be reasoning about size variables.
| if not isinstance(a, SymInt): | ||
| assert min <= a <= max | ||
| return | ||
| if isinstance(a.node.expr, sympy.Integer): |
There was a problem hiding this comment.
any reason not to support Floats here ?
There was a problem hiding this comment.
Same deal, not supporting constraints on floats for now
This PR introduces a new `constrain_range` function which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard. The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work. Signed-off-by: Edward Z. Yang <ezyangmeta.com> [ghstack-poisoned]
|
oops this broke convit_base |
|
@pytorchbot revert -m "Breaking internal builds, more details can be found: https://fburl.com/phabricator/fq5b6k8a" -c nosignal |
|
@pytorchbot successfully started a revert job. Check the current status here. |
|
@ezyang your PR has been successfully reverted. |
This reverts commit 3711f7c. Reverted #95063 on behalf of https://github.com/jeanschmidt due to Breaking internal builds, more details can be found: https://fburl.com/phabricator/fq5b6k8a
This reverts commit 4e88547. [ghstack-poisoned]
…5209) This reverts commit 4e88547. Pull Request resolved: #95209 Approved by: https://github.com/albanD
…)" (#95209)" This reverts commit f7bf31f. Reverted #95209 on behalf of https://github.com/ezyang due to internal sympy is too old
…5209) This reverts commit 4e88547. Pull Request resolved: #95209 Approved by: https://github.com/albanD
This reverts commit 3711f7c. Reverted pytorch/pytorch#95063 on behalf of https://github.com/jeanschmidt due to Breaking internal builds, more details can be found: https://fburl.com/phabricator/fq5b6k8a
…rch#95063)" (pytorch#95209)" This reverts commit 3758559.
…bs (pytorch#95063)" (pytorch#95209)"" This reverts commit cf6e078.
…rch#95063)" (pytorch#95209)" This reverts commit f7bf31f.
…rch#95063)"" This reverts commit 4e88547.
This reverts commit 3711f7c.
This PR introduces a new `constrain_range` function which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard. The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work. Signed-off-by: Edward Z. Yang <ezyang@meta.com> Pull Request resolved: pytorch#95063 Approved by: https://github.com/eellison
This reverts commit 3711f7c. Reverted pytorch#95063 on behalf of https://github.com/jeanschmidt due to Breaking internal builds, more details can be found: https://fburl.com/phabricator/fq5b6k8a
…" (pytorch#95209) This reverts commit 4e88547. Pull Request resolved: pytorch#95209 Approved by: https://github.com/albanD
…rch#95063)" (pytorch#95209)" This reverts commit f7bf31f. Reverted pytorch#95209 on behalf of https://github.com/ezyang due to internal sympy is too old
…" (pytorch#95209) This reverts commit 4e88547. Pull Request resolved: pytorch#95209 Approved by: https://github.com/albanD
Stack from ghstack (oldest at bottom):
This PR introduces a new
constrain_rangefunction which can be used to constrain the possible values a SymInt/SymFloat can take on. This knowledge can be then used to discharge potential guards (by running the range analysis, and then seeing if the guard must be true given the original range) without adding another guard.The usage of ranges is very limited right now; ranges are only constrained when the user explicitly instructs the system so. However, we can also infer range constraints based on guards as well; this is left for future work.
Signed-off-by: Edward Z. Yang ezyang@meta.com