split out functionalization codegen to use view_copy operators by bdhirsh · Pull Request #75302 · pytorch/pytorch

bdhirsh · 2022-04-06T00:56:24Z

This PR splits the functionalization codegen into 2 pieces:

(1) Vanilla functionalization will now always turn view ops into "view_copy" ops.

(2) For functorch to "reapply views underneath the pass", I added a new dispatch key, "FunctionalizeAddBackViews". I codegen a kernel to that key for every view_copy operator that just calls back into the view op. All other ops get a fallthrough kernel.

Also - the codegen will now unconditionally register CompositeImplicitAutograd kernels directly to the functionalization keys, so we "always decompose" before hitting functionalization. Otherwise, we might break and accidentally send "view" calls to the backend, if we decompose an op into a view underneath the functionalization pass.

The important changes are in gen.py and gen_functionalization_type.py - most of the other changes are just plumbing {view}_copy everywhere. I also updated test_functionalization.py, and added expecttests for the "add back views" case.

One thing about the AddBackViews key - right now, I add it into the TLS include set. The other option would be to try to add it directly to the tensors, but that's kind of hard: putting it on the FunctionalTensorWrapper doesn't help, because the functionalization pass will unwrap when it calls back into the dispatcher, and run on the "inner tensor" (maybe we could modify the inner tensor's keyset and add the AddBackViews key when functionalization happens, instead?)

I also have an accompanying functorch change here: pytorch/functorch#678

Stack from ghstack:

integrate functionalization <> LTC torchscript backend #75527 [prototype] integrate functionalization <> LTC torchscript backend
functionalization: introduce a "zero()" aten op #75913 functionalization: introduce a "zero()" aten op
functionalization: avoid some unnecessary view_copy calls #75819 functionalization: avoid some unnecessary view_copy calls
fix unfold for meta tensors #75717 fix unfold for meta tensors
teach ivalue about List[Optional[Tensor]], fix fallbacks #75716 teach ivalue about List[Optional[Tensor]], fix fallbacks
fix out= op handling for functionalization #75818 fix out= op handling for functionalization
split out functionalization codegen to use view_copy operators #75302 split out functionalization codegen to use view_copy operators

Differential Revision: D35419652

[ghstack-poisoned]

facebook-github-bot · 2022-04-06T00:56:29Z

🔗 Helpful links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/75302
📄 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 our office hours

💊 CI failures summary and remediations

As of commit 2bdc99d (more details on the Dr. CI page):

💚 💚 Looks good so far! There are no failures yet. 💚 💚

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

…tors" [ghstack-poisoned]

ghstack-source-id: 00de995 Pull Request resolved: #75302

bdhirsh · 2022-04-06T01:02:57Z

@bdhirsh has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

ghstack-source-id: 61fa919 Pull Request resolved: #75302

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh · 2022-04-06T14:48:57Z

@bdhirsh has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

ghstack-source-id: 3b5da83 Pull Request resolved: #75302

bdhirsh · 2022-04-06T15:28:03Z

@bdhirsh has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

ghstack-source-id: 492d96b Pull Request resolved: #75302

bdhirsh · 2022-04-07T17:53:08Z

@bdhirsh has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

ghstack-source-id: a1ed30d Pull Request resolved: #75302

albanD · 2022-04-08T15:45:57Z

torch/csrc/autograd/python_torch_functions_manual.cpp

 {
  HANDLE_TH_ERRORS
  c10::impl::tls_set_dispatch_key_included(at::DispatchKey::Functionalize, false);
+  c10::impl::tls_set_dispatch_key_included(at::DispatchKey::FunctionalizeAddBackViews, false);


Isn't this going to prevent clean nesting?
In particular, if the python API should be a context manager, I would expect that it will re-set the state that was there before.
But maybe that's not considered here? If so, should we just forbid enabling it if it is already enabled?

Yeah you're right, I wasn't thinking too much about the nesting case. Maybe I'll just forbid it now until there's a need.

albanD · 2022-04-08T15:51:48Z

tools/codegen/context.py


 # Convenience decorator for functions that explicitly take in a BackendIndex,
 # instead of indirectly taking one in as a closure
-def with_native_function_and_selector_and_index(


The comment above should go as well no?

The comment also applies to the wrapper below the one that I deleted (technically it takes a dict of BackendIndices, I can fix that)

albanD · 2022-04-08T15:53:01Z

tools/codegen/gen.py

+            'ops_headers',
+            'func_definitions',
+            'func_registrations',
+            'func_add_back_views_definitions',


Do we really need to shard since this is only for view functions?

~~yeah this is definitely overkill. Let me try to unwind it.~~

It's for all view + inplace + out= ops actually, which is quite large. Right now the 4 generated files are each 10k lines long.

Ho the out ops are there? Then yes makes sense.

tools/codegen/gen_functionalization_type.py

…tors" This PR splits the functionalization codegen into 2 pieces: (1) Vanilla functionalization will now always turn view ops into "view_copy" ops. (2) For functorch to "reapply views underneath the pass", I added a new dispatch key, "FunctionalizeAddBackViews". I codegen a kernel to that key for every view_copy operator that just calls back into the view op. All other ops get a fallthrough kernel. Also - the codegen will now unconditionally register CompositeImplicitAutograd kernels directly to the functionalization keys, so we "always decompose" before hitting functionalization. Otherwise, we might break and accidentally send "view" calls to the backend, if we decompose an op into a view underneath the functionalization pass. The important changes are in `gen.py` and `gen_functionalization_type.py` - most of the other changes are just plumbing `{view}_copy` everywhere. I also updated `test_functionalization.py`, and added expecttests for the "add back views" case. One thing about the `AddBackViews` key - right now, I add it into the TLS include set. The other option would be to try to add it directly to the tensors, but that's kind of hard: putting it on the `FunctionalTensorWrapper` doesn't help, because the functionalization pass will unwrap when it calls back into the dispatcher, and run on the "inner tensor" (maybe we could modify the inner tensor's keyset and add the `AddBackViews` key when functionalization happens, instead?) I also have an accompanying functorch change here: pytorch/functorch#678 Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

ezyang · 2022-04-15T02:08:57Z

c10/core/DispatchKey.h

  // removal,
  // we can consider adding separate keys dedicated to those individual passes.
  // See Note [Functionalization Pass In Core] for details.
+  FunctionalizeAddBackViews,


I'm wondering if we actually need a separate key for this. An alternative is to just have some TLS that Functionalize queries when implementing _copy operations.

Yeah I think I should just do this. We'll save the extra key, and it also feels easier to reason about than the extra redispatch (where in functorch, now you need to worry about having two redispatch's "sandwiched" inside of DynamicLayer).

Current plan: we already have a FuncTorchTLS construct in core, and AddBackViews is currrently only a useful concept in the context of the functionalize() transform, so I'm thinking of adding a flag in there for it.

The functionalize view kernels would just check that TLS right before redispatching (to either a view or a view_copy op), and functorch's DynamicLayer logic would be responsible for setting / un-setting that TLS upon entering / exiting the layer.

(We could probably do something really similar for "preserving mutations"- I remember discussions about that being useful to mobile).

ezyang · 2022-04-15T02:11:41Z

tools/codegen/api/types.py

        # Some assertions: lambdas are only used for view ops
        assert f.is_view_op
-        assert functional_op.is_view_op
+        assert not functional_op.is_view_op


(i felt the same way lol)

Context: before this PR, we have view_inplace kernels that would redispatch to the view kernel (transpose_ to transpose). So the "functional_op" here was transpose, and both were view ops.

Now, f will be either a view or view_inplace op, and functional_op will always be the view_copy op.

ezyang · 2022-04-15T02:15:14Z

tools/codegen/gen_functionalization_type.py

 #     Generates view_copy() composite kernels for all view_copy operators.


+FunctionalizationTarget = Enum('Target', (


'FunctionalizationTarget', not 'Target'

Also, Target is intended to be open, so you could add these there. Though, I'd probably try to follow the existing naming convention (which tries to say if you are DEFINITION or DECLARATION in the name) more closely

ezyang · 2022-04-15T02:18:54Z

tools/codegen/gen.py

+                g,
+                backend_indices[DispatchKey.CompositeImplicitAutograd],
+                FunctionalizationTarget.ADD_BACK_VIEWS,
+            ),


It's not clear to me why you don't just generate both the addbackviews and regular things all in one go in a gen_functionalization_registration call. Save you a lot of typing here.

(the thing Target exists for is when you're mapping over a list of functions, but no mapping is going on here...)

ezyang · 2022-04-15T02:20:15Z

updated codegen output would be much appreciated

ezyang · 2022-04-15T02:21:30Z

tools/codegen/gen_functionalization_type.py

-    view_inverse_sig = ViewInverseSignature(f)
-    return view_inverse_sig.decl()
+    view_api_name = g.view.func.name.unambiguous_name()
+    exprs = ', '.join([e.expr for e in translate(view_copy_sig.arguments(), view_sig.arguments())])


Sometime we should add some APIs that make doing this kind of "call-to-call" less wordy haha

ezyang · 2022-04-15T02:35:52Z

tools/codegen/gen_functionalization_type.py

@@ -29,6 +32,11 @@
 #     Generates view_copy() composite kernels for all view_copy operators.


This comment needs a nice, long update

yeah... it's actually up-to-date again now that I removed all of the AddBackView kernels

ezyang · 2022-04-15T02:38:41Z

tools/codegen/gen_functionalization_type.py

+    funcTarget: FunctionalizationTarget,
 ) -> List[str]:
-    if not needs_functionalization(selector, g):
+    if not needs_functionalization(selector, g, Target.ANONYMOUS_DEFINITION, funcTarget):


how come this one is anonymous?

ezyang · 2022-04-15T02:39:47Z

tools/codegen/gen_functionalization_type.py

-        f = g
-        assert modifies_arguments(f)
-        return [emit_inplace_functionalization_body(f, functional_op)]
+    if funcTarget == FunctionalizationTarget.FUNCTIONALIZATION:


it's more idiomatic to do these conditions as

if funcTarget is FunctionalizationTarget.FUNCTIONALIZATION: ... elif funcTarget is FunctionalizationTarget.ADD_BACK_VIEWS: ... else: assert_never(funcTarget)

you then get compile time exhaustiveness checking

ah yep - this will go away though if I'm using TLS to keep the views around instead of an extra dispatch key / set of kernels to generate.

ezyang · 2022-04-15T02:42:49Z

tools/codegen/gen_functionalization_type.py


-# TODO: later, I'll generate separate kernels for "Functionalize", and "AddBackViews"
-# That will probably be an enum, that this function will take in to know which ops get kernels.
 def needs_functionalization(


as you are now unconditionally calling gen_ops_header, it doesn't seem to me like there is any good reason to have factored out the needs functionalization boolean test from the actual codegen. Just do the eligibility test in the codegen; it's not like you're saving any work splitting it up this way, and then you have less asserts to do in the actual generating code.

ezyang · 2022-04-15T02:46:23Z

tools/codegen/gen_functionalization_type.py

+        if isinstance(g, NativeFunctionsViewGroup):
+            # Case 1: emit view -> view_copy kernels for the functionalization pass
+            view_defs = []
+            if not g.view.has_composite_implicit_autograd_kernel:


I understand this is from preexisting code, but the test for g.view.has_composite_implicit_autograd_kernel seems very obscure. All you're really doing is trying to distinguish between composite views and non-composite views. Is there any reason to put composite views in NativeFunctionsViewGroup? And if so, it seems like it would be better to have this be a property on NativeFunctionsViewGroup itself that can then be documented on what its semantic meaning. Directly referencing has_composite_implicit_autograd_kernel feels super low level for the logic here.

The code here allows for the possibility of a view op being CompositeImplicitAutograd but its view_inplace variant to not be (or vice versa).

I just checked though and as per your comment further down: we don't actually have an ops like that today. So maybe I should just enforce "composite-ness" between view and view_inplace ops and simplify this code (make compositeness a property of the group).

Yeah, if you can enforce a more restrictive check, defo go for it.

ezyang · 2022-04-15T02:47:10Z

tools/codegen/gen_functionalization_type.py

+                # if the view is not composite (implicit autograd)
+                assert g.view_copy is not None
+                view_defs.append(emit_view_functionalization_body(g.view, g.view_copy))
+            if g.view_inplace is not None and not g.view_inplace.has_composite_implicit_autograd_kernel:


is it ever the case that the view inplace has composite implicit autograd, but the view doesn't (or vice versa?)

(commented above - as of today, nope)

ezyang · 2022-04-15T02:51:01Z

tools/codegen/gen_functionalization_type.py

-            view_str.append(emit_registration_helper(g.view_inplace, is_view=True))
-        return view_str
+        # we always want to register composite kernels
+        if g.view.has_composite_implicit_autograd_kernel:


The control flow here matches exactly the codegen logic below, is that right? This is exactly what Target was about; rather than having to keep the control flow thicket in sync, instead you just reuse the control flow and on the inside you then case on the target, so you only have to say the control flow once.

ezyang

This looks functionally correct but I do think it can be cleaner.

…tors" This PR splits the functionalization codegen into 2 pieces: (1) Vanilla functionalization will now always turn view ops into "view_copy" ops. (2) For functorch to "reapply views underneath the pass", I added a new dispatch key, "FunctionalizeAddBackViews". I codegen a kernel to that key for every view_copy operator that just calls back into the view op. All other ops get a fallthrough kernel. Also - the codegen will now unconditionally register CompositeImplicitAutograd kernels directly to the functionalization keys, so we "always decompose" before hitting functionalization. Otherwise, we might break and accidentally send "view" calls to the backend, if we decompose an op into a view underneath the functionalization pass. The important changes are in `gen.py` and `gen_functionalization_type.py` - most of the other changes are just plumbing `{view}_copy` everywhere. I also updated `test_functionalization.py`, and added expecttests for the "add back views" case. One thing about the `AddBackViews` key - right now, I add it into the TLS include set. The other option would be to try to add it directly to the tensors, but that's kind of hard: putting it on the `FunctionalTensorWrapper` doesn't help, because the functionalization pass will unwrap when it calls back into the dispatcher, and run on the "inner tensor" (maybe we could modify the inner tensor's keyset and add the `AddBackViews` key when functionalization happens, instead?) I also have an accompanying functorch change here: pytorch/functorch#678 Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh · 2022-04-15T22:27:03Z

Pushed another round of updates. List of changes:

(1) Removed the FunctionalizeAddBackViews dispatch key, and used TLS instead, inside of the functionalization kernels, to decide whether or not I redispatch to a view or view_copy operator.

The main annoying thing here is for the view_inverse lambdas. I didn't want to have to manually write out twice as many "view_inverse" functions, so instead I updated them all to plumb through a reapply_views argument, which they use to decide whether to call the underlying view or view_copy op. I had to update the at::sum_to() helper to also take in an optional always_return_non_views flag (thought it was cleaner than duplicating the function just for functionalization).

(2) removed needs_functionalization() since it was redundant, and cleaned up the "when to generate a kernel" logic a bit by making composite a property of the NativeFunctionsViewGroup. Turns out there is one view group that doesn't have matching composite info: narrow is CompositeImplicitAutograd, but narrow_copy is Composite

(3) I ended up plumbing NativeFunctionsViewGroup further into the codegen layer, into FunctionalizationLambda. This let me remove a few assertions, and also fixed an issue where in the AddBackView case for transpose_(), I needed to be able to have access to the name + schema of the view op transpose() (before I only had the view_inplace and view_copy lying around).

…tors" This PR splits the functionalization codegen into 2 pieces: (1) Vanilla functionalization will now always turn view ops into "view_copy" ops. (2) For functorch to "reapply views underneath the pass", I added a new dispatch key, "FunctionalizeAddBackViews". I codegen a kernel to that key for every view_copy operator that just calls back into the view op. All other ops get a fallthrough kernel. Also - the codegen will now unconditionally register CompositeImplicitAutograd kernels directly to the functionalization keys, so we "always decompose" before hitting functionalization. Otherwise, we might break and accidentally send "view" calls to the backend, if we decompose an op into a view underneath the functionalization pass. The important changes are in `gen.py` and `gen_functionalization_type.py` - most of the other changes are just plumbing `{view}_copy` everywhere. I also updated `test_functionalization.py`, and added expecttests for the "add back views" case. One thing about the `AddBackViews` key - right now, I add it into the TLS include set. The other option would be to try to add it directly to the tensors, but that's kind of hard: putting it on the `FunctionalTensorWrapper` doesn't help, because the functionalization pass will unwrap when it calls back into the dispatcher, and run on the "inner tensor" (maybe we could modify the inner tensor's keyset and add the `AddBackViews` key when functionalization happens, instead?) I also have an accompanying functorch change here: pytorch/functorch#678 Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh · 2022-04-17T01:01:39Z

@bdhirsh has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

ezyang · 2022-04-17T03:13:35Z

I didn't want to have to manually write out twice as many "view_inverse" functions, so instead I updated them all to plumb through a reapply_views argument, which they use to decide whether to call the underlying view or view_copy op.

This seems troublesome, because doesn't this make it impossible to give accurate schema information for the view inverse function? You don't know if it will alias or not without knowing the boolean setting.

facebook-github-bot · 2022-04-18T20:04:02Z

@pytorchbot merge this

(Initiating merge automatically since Phabricator Diff has merged)

pytorchmergebot · 2022-04-18T20:05:30Z

Can't merge closed PR #75302

Summary: Pull Request resolved: #75302 Test Plan: Imported from OSS Reviewed By: ezyang Differential Revision: D35419652 Pulled By: bdhirsh fbshipit-source-id: 26c1249a4e2c8d606f9275b5c59970c3abd0886f

Pull Request resolved: #75302 Approved by: https://github.com/ezyang (cherry picked from commit cb17973)

split out functionalization codegen to use view_copy operators

f25765c

[ghstack-poisoned]

bdhirsh requested review from albanD and soulitzer as code owners April 6, 2022 00:56

bdhirsh mentioned this pull request Apr 6, 2022

code-generate non-aliasing {view}_copy kernels #73442

Closed

facebook-github-bot added the cla signed label Apr 6, 2022

Update on "split out functionalization codegen to use view_copy opera…

f7e4830

…tors" [ghstack-poisoned]

bdhirsh added a commit that referenced this pull request Apr 6, 2022

split out functionalization codegen to use view_copy operators

b75c935

ghstack-source-id: 00de995 Pull Request resolved: #75302

Update on "split out functionalization codegen to use view_copy opera…

ff0dd4b

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh added a commit that referenced this pull request Apr 6, 2022

split out functionalization codegen to use view_copy operators

fcfeba1

ghstack-source-id: 61fa919 Pull Request resolved: #75302

Update on "split out functionalization codegen to use view_copy opera…

cb52cb3

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

Update on "split out functionalization codegen to use view_copy opera…

41f1d0f

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh added a commit that referenced this pull request Apr 6, 2022

split out functionalization codegen to use view_copy operators

a31117e

ghstack-source-id: 3b5da83 Pull Request resolved: #75302

Update on "split out functionalization codegen to use view_copy opera…

ba93404

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh added a commit that referenced this pull request Apr 7, 2022

split out functionalization codegen to use view_copy operators

ef03f0f

ghstack-source-id: 492d96b Pull Request resolved: #75302

Update on "split out functionalization codegen to use view_copy opera…

ba2bd52

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

Update on "split out functionalization codegen to use view_copy opera…

8d0de6b

…tors" Differential Revision: [D35419652](https://our.internmc.facebook.com/intern/diff/D35419652) [ghstack-poisoned]

bdhirsh added a commit that referenced this pull request Apr 8, 2022

split out functionalization codegen to use view_copy operators

2b3fb91

ghstack-source-id: a1ed30d Pull Request resolved: #75302

bdhirsh mentioned this pull request Apr 8, 2022

functionalize(): make "additionally removing views" toggleable pytorch/functorch#678

Merged

albanD reviewed Apr 8, 2022

View reviewed changes

bdhirsh mentioned this pull request Apr 8, 2022

integrate functionalization <> LTC torchscript backend #75527

Closed

bdhirsh mentioned this pull request Apr 13, 2022

teach ivalue about List[Optional[Tensor]], fix fallbacks #75716

Closed

bdhirsh mentioned this pull request Apr 14, 2022

functionalization: avoid some unnecessary view_copy calls #75819

Closed

bdhirsh added 2 commits April 14, 2022 13:37

ezyang reviewed Apr 15, 2022

View reviewed changes

ezyang approved these changes Apr 15, 2022

View reviewed changes

bdhirsh mentioned this pull request Apr 15, 2022

functionalization: introduce a "zero()" aten op #75913

Closed

pytorchmergebot closed this in cb17973 Apr 18, 2022

malfet pushed a commit that referenced this pull request Apr 20, 2022

split out functionalization codegen to use view_copy operators

26e2759

Pull Request resolved: #75302 Approved by: https://github.com/ezyang (cherry picked from commit cb17973)

facebook-github-bot deleted the gh/bdhirsh/197/head branch April 22, 2022 14:17

		# Generates view_copy() composite kernels for all view_copy operators.


		FunctionalizationTarget = Enum('Target', (

		@@ -29,6 +32,11 @@
		# Generates view_copy() composite kernels for all view_copy operators.

Conversation

bdhirsh commented Apr 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

facebook-github-bot commented Apr 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful links

💊 CI failures summary and remediations

Uh oh!

bdhirsh commented Apr 6, 2022

Uh oh!

bdhirsh commented Apr 6, 2022

Uh oh!

bdhirsh commented Apr 6, 2022

Uh oh!

bdhirsh commented Apr 7, 2022

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!

bdhirsh Apr 8, 2022 • 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bdhirsh Apr 15, 2022 • 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!

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 Apr 15, 2022

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!

Choose a reason for hiding this comment

Uh oh!

ezyang Apr 15, 2022 • 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!

Choose a reason for hiding this comment

Uh oh!

bdhirsh commented Apr 6, 2022 •

edited

Loading

facebook-github-bot commented Apr 6, 2022 •

edited

Loading

bdhirsh Apr 8, 2022 •

edited

Loading

bdhirsh Apr 15, 2022 •

edited

Loading

ezyang Apr 15, 2022 •

edited

Loading