Unbacked SymInt fixes for subclasses + data-dependent slice() bounds #142062

jbschlosser · 2024-12-04T18:23:40Z

Stack from ghstack (oldest at bottom):

Related: #125914 (specifically see comment)

This PR addresses two broken things involving the usage of unbacked SymInts for calls to slice() with data-dependent bounds. These issues are encountered in practice for narrow() operating on the batch dim with an NJT input, but apply to other subclasses as well. The test in this PR uses a purpose-built subclass.

There are two different issues here, depending on whether torch.compile() is called with dynamic=True. In practice, these only occur when the unbacked SymInts are created within the torch_dispatch implementation of a subclass, because the unbacked symbols are considered "freshly created" when the output subclass instance is handled in Dynamo.

Error 1 (dynamic=False):

LoweringException: GuardOnDataDependentSymNode: Could not guard on data-dependent expression Eq(-Min(22, Max(0, u0)) + Min(22, Max(u0 + u1, Max(0, u0))), 0) (unhinted: Eq(-Min(s0, Max(0, u0)) + Min(s0, Max(u0 + u1, Max(0, u0))), 0)).  (Size-like symbols: u1, u0)

The expression comes from the use of clamp() logic for SliceView in Inductor:

pytorch/torch/_inductor/ir.py

Line 3014 in 41e5975

return sympy.Min(sympy.Max(x, lower), upper)

If the (start, end) bounds for the slice() are statically known to be in range for the given dim (e.g. provided via torch._check() calls), we can avoid this clamp() logic and the error. This PR implements this fix.

Error 2 (dynamic=True):

torch._dynamo.exc.InternalTorchDynamoError: PendingUnbackedSymbolNotFound: Pending unbacked symbols {u0} not in returned outputs NestedTensor(size=(2, s16, s1), offsets=FakeTensor(..., device='cuda:0', size=(3,), dtype=torch.int64), grad_fn=<NarrowBackwardAutogradNestedTensor0 object at 0x7f1f8603cfd0>, contiguous=True) ((s1*s16, s1, 1), s1*u0)

The storage offset of the values component of the returned NJT is s1*u0 where s1 is known to be an integer. This PR expands the special logic handling the constant * u0 case to handle SymInts as well:

pytorch/torch/fx/experimental/symbolic_shapes.py

Lines 1013 to 1031 in 314e08e

    
           # When an unbacked SymInt is perfectly divisible by an integer 
        
           # constant, we replace it with the integer constant to improve 
        
           # reasoning capabilities.  However, in synthetic examples, it is 
        
           # then possible that the factor never is explicitly allocated. 
        
           # Fortunately, we can compute it by division. 
        
           elif ( 
        
               isinstance(a, torch.SymInt) 
        
               and isinstance(s := a.node._expr, sympy.Mul) 
        
               and len(s.args) == 2 
        
               and isinstance(lhs := s.args[0], sympy.Integer) 
        
               and isinstance(rhs := s.args[1], sympy.Symbol) 
        
               and rhs in pending 
        
           ): 
        
               # TODO: DivideByKey needs to test divisibility at runtime! 
        
               r[rhs] = path + (DivideByKey(int(lhs)),) 
        
               if real is not None: 
        
                   assert isinstance(real, int) 
        
                   shape_env.set_unbacked_var_to_val(rhs, real // int(lhs)) 
        
               pending.remove(rhs)

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

[ghstack-poisoned]

pytorch-bot · 2024-12-04T18:23:44Z

🔗 Helpful Links

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

📄 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.

✅ No Failures

As of commit 28ae4f8 with merge base e885225 ():
💚 Looks good so far! There are no failures yet. 💚

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

…e() bounds" Related: #125914 (specifically see [comment](#125914 (comment))) This PR addresses two broken things involving the usage of unbacked SymInts for calls to `slice()` with data-dependent bounds. These issues are encountered in practice for `narrow()` operating on the batch dim with an NJT input, but apply to other subclasses as well. The test in this PR uses a purpose-built subclass. There are two different issues here, depending on whether `torch.compile()` is called with `dynamic=True`. In practice, these only occur when the unbacked SymInts are created within the torch_dispatch implementation of a subclass, because the unbacked symbols are considered "freshly created" when the output subclass instance is handled in Dynamo. **Error 1 (dynamic=False):** ``` LoweringException: GuardOnDataDependentSymNode: Could not guard on data-dependent expression Eq(-Min(22, Max(0, u0)) + Min(22, Max(u0 + u1, Max(0, u0))), 0) (unhinted: Eq(-Min(s0, Max(0, u0)) + Min(s0, Max(u0 + u1, Max(0, u0))), 0)). (Size-like symbols: u1, u0) ``` The expression comes from the use of `clamp()` logic for `SliceView` in Inductor: https://github.com/pytorch/pytorch/blob/41e59754b407533b060b874c22ca4feda38bd83a/torch/_inductor/ir.py#L3014 If the (start, end) bounds for the `slice()` are statically known to be in range for the given dim (e.g. provided via `torch._check()` calls), we can avoid this `clamp()` logic and the error. This PR implements this fix. **Error 2 (dynamic=True):** ``` torch._dynamo.exc.InternalTorchDynamoError: PendingUnbackedSymbolNotFound: Pending unbacked symbols {u0} not in returned outputs NestedTensor(size=(2, s16, s1), offsets=FakeTensor(..., device='cuda:0', size=(3,), dtype=torch.int64), grad_fn=<NarrowBackwardAutogradNestedTensor0 object at 0x7f1f8603cfd0>, contiguous=True) ((s1*s16, s1, 1), s1*u0) ``` The storage offset of the values component of the returned NJT is `s1*u0` where `s1` is known to be an integer. This PR expands the special logic handling the `constant * u0` case to handle SymInts as well: https://github.com/pytorch/pytorch/blob/314e08eb52ad0e9b1c3eb6e149ec8a452e05b9c3/torch/fx/experimental/symbolic_shapes.py#L1013-L1031 cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv voznesenskym penguinwu Guobing-Chen XiaobingSuper zhuhaozhe blzheng jiayisunx ipiszy yf225 chenyang78 kadeng muchulee8 ColinPeppler amjames desertfire chauhang aakhundov [ghstack-poisoned]

torch/_inductor/ir.py

torch/fx/passes/runtime_assert.py

ezyang · 2024-12-06T14:45:19Z

What I am missing right now is a more detailed step through of how exactly we end up in the situation here

The storage offset of the values component of the returned NJT is s1*u0 where s1 is known to be an integer. This PR expands the special logic handling the constant * u0 case to handle SymInts as well:

Going to carefully read the unit test now.

ezyang · 2024-12-06T14:45:57Z

Adding @bdhirsh @IvanKobzarev as there are subclasses involved

ezyang · 2024-12-06T14:46:41Z

test/inductor/test_unbacked_symints.py

+        # return value of the torch_dispatch is handled.
+        # Subclass forwards everything along to the single underlying dense tensor
+        # component, except for slice(), which it handles via data-dependent bounds access
+        class CustomSliceSubclass(WrapperTensor):


@bdhirsh Do we have a clear description of the correctness invariants for tensor subclasses that have dynamic shapes anywhere?

ezyang · 2024-12-06T14:48:26Z

test/inductor/test_unbacked_symints.py

+
+            @classmethod
+            def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
+                if func is torch.ops.aten.slice.Tensor:


So, if I understand correctly, when we do Dynamo tracing, we will end up with a torch.ops.aten.slice.Tensor node in the graph, which is taking the subclass in as an argument. So for the purpose of unbacked_binding calculation, we must be able to determine the allocated unbacked SymInts from the returned tensor of this subclass slice operation?

we will end up with a torch.ops.aten.slice.Tensor node in the graph, which is taking the subclass in as an argument.

yep, this is correct.

So for the purpose of unbacked_binding calculation, we must be able to determine the allocated unbacked SymInts from the returned tensor of this subclass slice operation?

yep that's my understanding as well. compute_unbacked_bindings() checks size / stride / storage_offset of subclass outer inner tensors for these unbacked SymInts. In particular for this subclass, t.storage_offset() will be <something> * u1 where <something> is a constant when dynamic=False and a backed SymInt when dynamic=True.

My point is that you shouldn't be detecting the offset from storage_offset. IMO, it should just be stored directly somewhere.

ezyang · 2024-12-06T15:07:04Z

test/inductor/test_unbacked_symints.py

+                    return CustomSliceSubclass(
+                        func(args[0].t, dim=0, start=start, end=(start + length)),
+                        slice_bounds=args[0].slice_bounds,
+                    )


OK, this looks pretty suspicious. Let me explain why.

If I am right in https://github.com/pytorch/pytorch/pull/142062/files#r1873458013 . This means that you are in the "this is a custom op that returns unbacked SymInt". The rule for custom ops that return unbacked SymInt is that they must return the SymInt in an "easy to access" way, because that is how we are going to learn how to bind it.

Now, the strategy you seem to have taken in this PR is to use DivideByKey to extract out the unbacked SymInt out of exactly how you have decided to define the slice subclass representation. But we should also examine whether or not the slice subclass representation should be represented differently.

In particular, you are storing slice_bounds as a Tensor. This seems pretty strange. You have accessed the raw int via the item() call. Why are you not just storing the item() directly?

I may need to understand the narrow PR better, I vaguely understand that it is data dependent inner size but I am also uncertain why the start and length are not just immediately derivable from the inner tensor without any division.

This means that you are in the "this is a custom op that returns unbacked SymInt". The rule for custom ops that return unbacked SymInt is that they must return the SymInt in an "easy to access" way, because that is how we are going to learn how to bind it.

This sounds right; in this case, the unbacked SymInt ends up in the storage_offset of the returned tensor's inner t tensor, but it's not trivial to access it there as there is a (either constant or SymInt) coefficient involved.

Now, the strategy you seem to have taken in this PR is to use DivideByKey to extract out the unbacked SymInt out of exactly how you have decided to define the slice subclass representation.

right, the strategy is to extract the unbacked symint out of the returned tensor's storage_offset by pulling it out of <coefficient> * u1 when <coefficient> is a SymInt.

But we should also examine whether or not the slice subclass representation should be represented differently.
In particular, you are storing slice_bounds as a Tensor. This seems pretty strange. You have accessed the raw int via the item() call. Why are you not just storing the item() directly?

I think in isolation updating the subclass representation could make sense. Unfortunately, this emulates NJT's storage of offsets as a Tensor. For NJT, the bounds for narrow() (and thus slice()) come from offsets data, so we can't store the item() directly.

I may need to understand the narrow PR better, I vaguely understand that it is data dependent inner size but I am also uncertain why the start and length are not just immediately derivable from the inner tensor without any division.

Summarizing the above: slice() / narrow() bounds come from data-dependent offsets access for NJT, both of these handle the start of the view by changing storage_offset to be <stride> * <start>, so the unbacked SymInt for the start of the range ends up in the inner tensor's storage_offset as <stride> * u1. If <stride> is a constant, there's no problem since we have logic for pulling unbacked SymInts out of <constant> * u1. If <stride> is a backed SymInt (as is the case when dynamic=True), we have problems, and this PR attempts to address this case through the use of DivideByKey with a backed SymInt divisor for <stride>.

…e() bounds" Related: #125914 (specifically see [comment](#125914 (comment))) This PR addresses two broken things involving the usage of unbacked SymInts for calls to `slice()` with data-dependent bounds. These issues are encountered in practice for `narrow()` operating on the batch dim with an NJT input, but apply to other subclasses as well. The test in this PR uses a purpose-built subclass. There are two different issues here, depending on whether `torch.compile()` is called with `dynamic=True`. In practice, these only occur when the unbacked SymInts are created within the torch_dispatch implementation of a subclass, because the unbacked symbols are considered "freshly created" when the output subclass instance is handled in Dynamo. **Error 1 (dynamic=False):** ``` LoweringException: GuardOnDataDependentSymNode: Could not guard on data-dependent expression Eq(-Min(22, Max(0, u0)) + Min(22, Max(u0 + u1, Max(0, u0))), 0) (unhinted: Eq(-Min(s0, Max(0, u0)) + Min(s0, Max(u0 + u1, Max(0, u0))), 0)). (Size-like symbols: u1, u0) ``` The expression comes from the use of `clamp()` logic for `SliceView` in Inductor: https://github.com/pytorch/pytorch/blob/41e59754b407533b060b874c22ca4feda38bd83a/torch/_inductor/ir.py#L3014 If the (start, end) bounds for the `slice()` are statically known to be in range for the given dim (e.g. provided via `torch._check()` calls), we can avoid this `clamp()` logic and the error. This PR implements this fix. **Error 2 (dynamic=True):** ``` torch._dynamo.exc.InternalTorchDynamoError: PendingUnbackedSymbolNotFound: Pending unbacked symbols {u0} not in returned outputs NestedTensor(size=(2, s16, s1), offsets=FakeTensor(..., device='cuda:0', size=(3,), dtype=torch.int64), grad_fn=<NarrowBackwardAutogradNestedTensor0 object at 0x7f1f8603cfd0>, contiguous=True) ((s1*s16, s1, 1), s1*u0) ``` The storage offset of the values component of the returned NJT is `s1*u0` where `s1` is known to be an integer. This PR expands the special logic handling the `constant * u0` case to handle SymInts as well: https://github.com/pytorch/pytorch/blob/314e08eb52ad0e9b1c3eb6e149ec8a452e05b9c3/torch/fx/experimental/symbolic_shapes.py#L1013-L1031 cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv voznesenskym penguinwu Guobing-Chen XiaobingSuper zhuhaozhe blzheng jiayisunx ipiszy yf225 chenyang78 kadeng muchulee8 ColinPeppler amjames desertfire chauhang aakhundov [ghstack-poisoned]

ezyang · 2024-12-06T18:59:34Z

test/inductor/test_unbacked_symints.py

+                    torch._check(start + length <= inp.size(0))
+
+                    return CustomSliceSubclass(
+                        func(args[0].t, dim=0, start=start, end=(start + length)),


To make narrow on narrow work, do this directly with as_strided and the unbacked symint is the FINAL offset

@ezyang turns out if I go this route, most of the fixes are no longer needed, AND narrow on narrow works.

Inductor-side clamp() checking for statically_known info: unneeded

Dynamic shapes support for pulling unbacked SymInt out of s0 * u0: unneeded

call_method support in _node_metadata_hook(): needed

do you think it's worth still following through with 1 or 2?

The clamp fix is harmless, I think, it could potentially result in slightly better code for unbacked SymInts. I think you did convince me that in principle pulling out u0 from s0 * u0 is potentially useful in the same way divisibility is useful. I'm fine if you drop both though, we can always do them later if we need it.

ezyang · 2024-12-06T19:02:10Z

1:1 discuss: the current design doesn't work if you narrow a narrow, Joel knows how to fix it

…e() bounds" Related: #125914 (specifically see [comment](#125914 (comment))) This PR addresses two broken things involving the usage of unbacked SymInts for calls to `slice()` with data-dependent bounds. These issues are encountered in practice for `narrow()` operating on the batch dim with an NJT input, but apply to other subclasses as well. The test in this PR uses a purpose-built subclass. There are two different issues here, depending on whether `torch.compile()` is called with `dynamic=True`. In practice, these only occur when the unbacked SymInts are created within the torch_dispatch implementation of a subclass, because the unbacked symbols are considered "freshly created" when the output subclass instance is handled in Dynamo. **Error 1 (dynamic=False):** ``` LoweringException: GuardOnDataDependentSymNode: Could not guard on data-dependent expression Eq(-Min(22, Max(0, u0)) + Min(22, Max(u0 + u1, Max(0, u0))), 0) (unhinted: Eq(-Min(s0, Max(0, u0)) + Min(s0, Max(u0 + u1, Max(0, u0))), 0)). (Size-like symbols: u1, u0) ``` The expression comes from the use of `clamp()` logic for `SliceView` in Inductor: https://github.com/pytorch/pytorch/blob/41e59754b407533b060b874c22ca4feda38bd83a/torch/_inductor/ir.py#L3014 If the (start, end) bounds for the `slice()` are statically known to be in range for the given dim (e.g. provided via `torch._check()` calls), we can avoid this `clamp()` logic and the error. This PR implements this fix. **Error 2 (dynamic=True):** ``` torch._dynamo.exc.InternalTorchDynamoError: PendingUnbackedSymbolNotFound: Pending unbacked symbols {u0} not in returned outputs NestedTensor(size=(2, s16, s1), offsets=FakeTensor(..., device='cuda:0', size=(3,), dtype=torch.int64), grad_fn=<NarrowBackwardAutogradNestedTensor0 object at 0x7f1f8603cfd0>, contiguous=True) ((s1*s16, s1, 1), s1*u0) ``` The storage offset of the values component of the returned NJT is `s1*u0` where `s1` is known to be an integer. This PR expands the special logic handling the `constant * u0` case to handle SymInts as well: https://github.com/pytorch/pytorch/blob/314e08eb52ad0e9b1c3eb6e149ec8a452e05b9c3/torch/fx/experimental/symbolic_shapes.py#L1013-L1031 cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv voznesenskym penguinwu Guobing-Chen XiaobingSuper zhuhaozhe blzheng jiayisunx ipiszy yf225 chenyang78 kadeng muchulee8 ColinPeppler amjames desertfire chauhang aakhundov [ghstack-poisoned]

ezyang

I would still much prefer this case be unified with the constant literal one

jbschlosser · 2024-12-19T16:32:52Z

I would still much prefer this case be unified with the constant literal one

will do :) Edit: done

…e() bounds" Related: #125914 (specifically see [comment](#125914 (comment))) This PR addresses two broken things involving the usage of unbacked SymInts for calls to `slice()` with data-dependent bounds. These issues are encountered in practice for `narrow()` operating on the batch dim with an NJT input, but apply to other subclasses as well. The test in this PR uses a purpose-built subclass. There are two different issues here, depending on whether `torch.compile()` is called with `dynamic=True`. In practice, these only occur when the unbacked SymInts are created within the torch_dispatch implementation of a subclass, because the unbacked symbols are considered "freshly created" when the output subclass instance is handled in Dynamo. **Error 1 (dynamic=False):** ``` LoweringException: GuardOnDataDependentSymNode: Could not guard on data-dependent expression Eq(-Min(22, Max(0, u0)) + Min(22, Max(u0 + u1, Max(0, u0))), 0) (unhinted: Eq(-Min(s0, Max(0, u0)) + Min(s0, Max(u0 + u1, Max(0, u0))), 0)). (Size-like symbols: u1, u0) ``` The expression comes from the use of `clamp()` logic for `SliceView` in Inductor: https://github.com/pytorch/pytorch/blob/41e59754b407533b060b874c22ca4feda38bd83a/torch/_inductor/ir.py#L3014 If the (start, end) bounds for the `slice()` are statically known to be in range for the given dim (e.g. provided via `torch._check()` calls), we can avoid this `clamp()` logic and the error. This PR implements this fix. **Error 2 (dynamic=True):** ``` torch._dynamo.exc.InternalTorchDynamoError: PendingUnbackedSymbolNotFound: Pending unbacked symbols {u0} not in returned outputs NestedTensor(size=(2, s16, s1), offsets=FakeTensor(..., device='cuda:0', size=(3,), dtype=torch.int64), grad_fn=<NarrowBackwardAutogradNestedTensor0 object at 0x7f1f8603cfd0>, contiguous=True) ((s1*s16, s1, 1), s1*u0) ``` The storage offset of the values component of the returned NJT is `s1*u0` where `s1` is known to be an integer. This PR expands the special logic handling the `constant * u0` case to handle SymInts as well: https://github.com/pytorch/pytorch/blob/314e08eb52ad0e9b1c3eb6e149ec8a452e05b9c3/torch/fx/experimental/symbolic_shapes.py#L1013-L1031 cc ezyang SherlockNoMad EikanWang jgong5 wenzhe-nrv voznesenskym penguinwu Guobing-Chen XiaobingSuper zhuhaozhe blzheng jiayisunx ipiszy yf225 chenyang78 kadeng muchulee8 ColinPeppler amjames desertfire chauhang aakhundov [ghstack-poisoned]

…(non-dynamic) (#143526) Lifted non-controversial (non-dynamic) fixes from #142062. See description there for context. Pull Request resolved: #143526 Approved by: https://github.com/ezyang

jbschlosser · 2024-12-19T19:04:10Z

@pytorchbot merge

pytorchmergebot · 2024-12-19T19:05:59Z

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

Unbacked SymInt fixes for slice() on subclasses

9ea484d

[ghstack-poisoned]

pytorch-bot bot added ciflow/inductor module: inductor release notes: fx release notes category labels Dec 4, 2024

jbschlosser mentioned this pull request Dec 4, 2024

Support narrow() on batch dim for NJT #142063

Closed

facebook-github-bot added the fx label Dec 4, 2024

jbschlosser added the topic: not user facing topic category label Dec 4, 2024

jbschlosser changed the title ~~Unbacked SymInt fixes for slice() on subclasses~~ Unbacked SymInt fixes for subclasses + data-dependent slice() bounds Dec 4, 2024

jbschlosser requested a review from ezyang December 4, 2024 18:37

jbschlosser added 2 commits December 5, 2024 11:44

jbschlosser mentioned this pull request Dec 5, 2024

Fix reductions for NJTs with ragged_idx != 1 #142173

Closed

ezyang requested review from bobrenjc93 and laithsakka December 6, 2024 14:39

ezyang reviewed Dec 6, 2024

View reviewed changes

torch/_inductor/ir.py Show resolved Hide resolved

ezyang reviewed Dec 6, 2024

View reviewed changes

torch/fx/passes/runtime_assert.py Outdated Show resolved Hide resolved

ezyang requested review from IvanKobzarev and bdhirsh December 6, 2024 14:45

ezyang reviewed Dec 6, 2024

View reviewed changes

jbschlosser mentioned this pull request Dec 11, 2024

Fix NJT backward tests #143072

Closed

jbschlosser added 2 commits December 11, 2024 17:44

jbschlosser mentioned this pull request Dec 16, 2024

Script to generate NJT OpInfo testing report #143311

Closed

jbschlosser added 2 commits December 17, 2024 16:04

jbschlosser mentioned this pull request Dec 18, 2024

Unbacked SymInt fixes for subclasses + data-dependent slice() bounds (non-dynamic) #143526

Closed

ezyang approved these changes Dec 18, 2024

View reviewed changes

pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Dec 19, 2024

pytorchmergebot added the merging label Dec 19, 2024

pytorchmergebot added the Merged label Dec 19, 2024

pytorchmergebot closed this in fc03c62 Dec 19, 2024

pytorchmergebot removed the merging label Dec 19, 2024

github-actions bot deleted the gh/jbschlosser/207/head branch January 19, 2025 02:08

	# When an unbacked SymInt is perfectly divisible by an integer
	# constant, we replace it with the integer constant to improve
	# reasoning capabilities. However, in synthetic examples, it is
	# then possible that the factor never is explicitly allocated.
	# Fortunately, we can compute it by division.
	elif (
	isinstance(a, torch.SymInt)
	and isinstance(s := a.node._expr, sympy.Mul)
	and len(s.args) == 2
	and isinstance(lhs := s.args[0], sympy.Integer)
	and isinstance(rhs := s.args[1], sympy.Symbol)
	and rhs in pending
	):
	# TODO: DivideByKey needs to test divisibility at runtime!
	r[rhs] = path + (DivideByKey(int(lhs)),)
	if real is not None:
	assert isinstance(real, int)
	shape_env.set_unbacked_var_to_val(rhs, real // int(lhs))
	pending.remove(rhs)

Unbacked SymInt fixes for subclasses + data-dependent slice() bounds #142062

Unbacked SymInt fixes for subclasses + data-dependent slice() bounds #142062

Uh oh!

Conversation

jbschlosser commented Dec 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pytorch-bot bot commented Dec 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

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

✅ No Failures

Uh oh!

Uh oh!

Uh oh!

ezyang commented Dec 6, 2024

Uh oh!

ezyang commented Dec 6, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jbschlosser Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ezyang commented Dec 6, 2024

Uh oh!

ezyang left a comment

Choose a reason for hiding this comment

Uh oh!

jbschlosser commented Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jbschlosser commented Dec 19, 2024

Uh oh!

pytorchmergebot commented Dec 19, 2024

Merge started

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jbschlosser commented Dec 4, 2024 •

edited

Loading

pytorch-bot bot commented Dec 4, 2024 •

edited

Loading

jbschlosser Dec 6, 2024 •

edited

Loading

jbschlosser commented Dec 19, 2024 •

edited

Loading