Add torch.library.custom_op #122344

zou3519 · 2024-03-20T20:52:28Z

Stack from ghstack (oldest at bottom):

This is the entrypoint for defining an opaque/blackbox (e.g. PyTorch will
never peek into it) custom op. In this PR, you can specify backend impls
and the abstract impl for this op.

NB: most of this PR is docstrings, please don't be intimidated by the
line count.

There are a number of interesting features:

we infer the schema from type hints. In a followup I add the ability
to manually specify a schema.
name inference. The user needs to manually specify an op name for now.
In a followup we add the ability to automatically infer a name (this
is a little tricky).
custom_op registrations can override each other. This makes them
more pleasant to work with in environments like colab.
we require that the outputs of the custom_op do not alias any inputs
or each other. We enforce this via a runtime check, but can relax this
into an opcheck test if it really matters in the future.

Test Plan:

new tests

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests [ghstack-poisoned]

pytorch-bot · 2024-03-20T20:52:31Z

🔗 Helpful Links

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

📄 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 ab8669d with merge base 31aff29 ():
💚 Looks good so far! There are no failures yet. 💚

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

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: 00ba59bba5a23e87053e823e1957e788eb3e1a70 Pull Request resolved: #122344

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: d70f2ac501a1d7233dbd37a450e38266432c7eb1 Pull Request resolved: #122344

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: f791b9abf0f07d7c9503fa48da06e7531fe05e47 Pull Request resolved: #122344

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: 96d3bc0808e93db7ee63980fa0d9d3ca6c652297 Pull Request resolved: #122344

test/test_custom_ops.py

Design doc: https://docs.google.com/document/d/13CS7nOEtTEsJ_0tiVGPhFDeYRbVb7LXIhw8atS-0eow/edit Prototype PR: #120345 This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: 633860fff828094a042dbdfad4f425689848a385 Pull Request resolved: #122344

Design doc: https://docs.google.com/document/d/13CS7nOEtTEsJ_0tiVGPhFDeYRbVb7LXIhw8atS-0eow/edit Prototype PR: #120345 This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: 165cd88503aff64b92898691823b2c89bfdf0a39 Pull Request resolved: #122344

Design doc: https://docs.google.com/document/d/13CS7nOEtTEsJ_0tiVGPhFDeYRbVb7LXIhw8atS-0eow/edit Prototype PR: #120345 This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang [ghstack-poisoned]

This is the entrypoint for defining a blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - we infer the namespace for the operator from the module. In a followup, we'll add the ability to manually specify a namespace. - def_blackbox registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the blackbox op do not alias any inputs or each other. We enforce this via a runtime check. Test Plan: - new tests ghstack-source-id: 3d8787c77d0148c25e4d5ca1476aad285ead78c1 Pull Request resolved: #122344

torch/_library/define.py

test/test_custom_ops.py

zou3519 · 2024-03-27T16:32:46Z

This should be ready for another review. TL;DR of changes:

naming changes per user/dev feedback
- def_blackbox -> custom_op
- impl -> register_impl
- impl_abstract -> register_fake
changed the mangling scheme as per comments

There are a number of TODOs in the code that I'd prefer to do as followups (this PR is getting long), but please lmk if you'd prefer any to be handled now.

test/test_custom_ops.py

torch/_library/custom_ops.py

albanD · 2024-03-27T20:55:00Z

torch/_library/custom_ops.py

+    ) -> Callable:
+        """Register an implementation for a device type for this operator.
+
+        Some valid types are: "cpu", "cuda", "xla", "mps", "ipu", "xpu".


Do we have a list of valid device strings anywhere?

torch/_library/custom_ops.py

albanD · 2024-03-27T20:58:43Z

torch/_library/custom_ops.py

+
+        """
+        self._abstract_fn = fn
+        return fn


Should this trigger a rebuild?

There's no rebuilds in the custom ops design?

Ho I though that's what the call in init self._build() is?

That only gets called once, when the user calls @custom_op. I'll rename it to something less confusing

albanD · 2024-03-27T20:59:58Z

torch/_library/custom_ops.py

+OPDEF_TO_LIB: Dict[str, "library.Library"] = {}
+
+
+def get_library_allowing_overwrite(namespace: str, name: str) -> "library.Library":


This will delete C++ or python manual registrations on rebuild?

This will delete the old library, which will delete all registrations associated with that library.

Not sure how this will play with C++ implemented kernels. But sounds ok.

We don't need to worry about that for now.

albanD · 2024-03-27T21:02:40Z

torch/library.py

@@ -178,6 +185,8 @@ def _destroy(self):
        for handle in self._registration_handles:
            handle.destroy()
        self._registration_handles.clear()
+        global _impls
+        _impls -= self._op_impls


That is a current bug?

albanD · 2024-03-27T21:13:48Z

torch/_library/custom_ops.py

+            >>>
+            >>> # Add implementations for the cuda device
+            >>> @numpy_sin.register_impl("cuda")
+            >>> def _(x):


tbh I think this will lead to more questions than anything else.
I think we should use a name that makes sense here or numpy_sin like is done with python property.

or numpy_sin like is done with python property.

What do you mean?

The default example for property from python is to name all of these the same: https://docs.python.org/3/library/functions.html#property.deleter

I need to go think about this a bit more

We've got four options:

@custom_op("mylib::sin", mutated_args=()) def sin(x): return x.clone() # Option 1: recommend underscore name (The python singledispatch way) # https://docs.python.org/3/library/functools.html#functools.singledispatch @sin.register_fake def _(x): return torch.empty_like(x) # Option 2: recommend a named name @sin.register_fake def sin_fake(x): return torch.empty_like(x) # Option 3: recommend the original name (The python property way) @sin.register_fake def sin(x): return torch.empty_like(x) # Option 4: recommend a random name with convention @sin.register_fake def impl(x): return torch.empty_like(x)

I don't like Option 2 and Option 3 because those have bitten me in the past:

Option 2 leads to unnecessarily verbose names and copy-paste confusion

Option 3 means there is no way to call any of the impls directly.

I don't really have a bone in this fight but Python singledispatch following the _ convention seems pretty compelling to me

This is the entrypoint for defining an opaque/blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - name inference. The user needs to manually specify an op name for now. In a followup we add the ability to automatically infer a name (this is a little tricky). - custom_op registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the custom_op do not alias any inputs or each other. We enforce this via a runtime check, but can relax this into an opcheck test if it really matters in the future. Test Plan: - new tests [ghstack-poisoned]

zou3519 · 2024-03-29T15:15:01Z

High-level updates:

I have split off the automatic namespace inference to a future PR, to not complicate this one (and because there's a lot of parallel work I want to do that is blocked on this PR). Instead, we require the user to pass in a manual name for their custom op in this PR
Updated with Alban's feedback

ezyang · 2024-03-29T16:23:44Z

torch/_library/custom_ops.py

+
+def custom_op(
+    name: str,
+    /,


ezyang · 2024-03-29T16:30:50Z

torch/_library/custom_ops.py

+            >>>
+            >>> # Add implementations for the cuda device
+            >>> @numpy_sin.register_impl("cuda")
+            >>> def _(x):


I don't really have a bone in this fight but Python singledispatch following the _ convention seems pretty compelling to me

ezyang · 2024-03-29T16:31:24Z

torch/_library/custom_ops.py

+    return lib
+
+
+def iter_tensors(


Intended to be private?

This is the entrypoint for defining an opaque/blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - name inference. The user needs to manually specify an op name for now. In a followup we add the ability to automatically infer a name (this is a little tricky). - custom_op registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the custom_op do not alias any inputs or each other. We enforce this via a runtime check, but can relax this into an opcheck test if it really matters in the future. Test Plan: - new tests [ghstack-poisoned]

albanD

Sounds good! Just a few nits/questions that can be done in follow ups

albanD · 2024-04-02T10:15:53Z

torch/library.py

@@ -16,6 +18,7 @@
    'fallthrough_kernel',
    'impl_abstract',
    'get_ctx',
+    'custom_op',


I'm surprised this is not tripping the public API checks. The __module__ being private shouldn't be ok...

It should definitely fail:

pytorch/test/test_public_bindings.py

Line 477 in 72662bf

'._' not in elem_module

Also because of this, we miss the fact that this is not properly documented on the website.

Lol we need to update the public bindings test to catch these cases

albanD · 2024-04-02T10:16:45Z

torch/_library/custom_ops.py

+    def check(arg):
+        if isinstance(arg, Tensor):
+            yield arg
+        elif allowed_nesting > 0 and isinstance(arg, (tuple, list)):


nit: typing says Tuple and this says tuple/list?
Should this just be Sequence?

The type hint says that args is a Tuple[Any]. arg is Any (and it may be a tuple or a list)

albanD · 2024-04-02T10:18:09Z

torch/_library/custom_ops.py

+
+
+def iter_tensors(
+    args: Tuple[Any], kwargs: Dict[str, Any], allowed_nesting: int = 1


Should we remove that allowed_nesting arg since it is never used?

That's a bug, thanks for the catch

Actually, I see what's going on. This function is recursive. Inside iter_tensors, I call iter_tensors with a different allowed_nesting.

albanD · 2024-04-02T10:20:53Z

torch/_library/custom_ops.py

+        self._abstract_fn = fn
+        return fn
+
+    def _register_to_dispatcher(self) -> None:


nit: "_define_in_dispatcher" ?

Well, we technically define + impl in this function

albanD · 2024-04-02T10:33:59Z

torch/_library/custom_ops.py

+        # Fields used to interface with the PyTorch dispatcher
+        self._namespace = namespace
+        self._name = name
+        self._qualname = f"{self._namespace}::{self._name}"


nit: make this a property computed dynamically removes the two source of truth and avoid potential divergence

This is the entrypoint for defining an opaque/blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - name inference. The user needs to manually specify an op name for now. In a followup we add the ability to automatically infer a name (this is a little tricky). - custom_op registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the custom_op do not alias any inputs or each other. We enforce this via a runtime check, but can relax this into an opcheck test if it really matters in the future. Test Plan: - new tests cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang [ghstack-poisoned]

Pull Request resolved: #123107 Approved by: https://github.com/soulitzer ghstack dependencies: #122344

This is the entrypoint for defining an opaque/blackbox (e.g. PyTorch will never peek into it) custom op. In this PR, you can specify backend impls and the abstract impl for this op. NB: most of this PR is docstrings, please don't be intimidated by the line count. There are a number of interesting features: - we infer the schema from type hints. In a followup I add the ability to manually specify a schema. - name inference. The user needs to manually specify an op name for now. In a followup we add the ability to automatically infer a name (this is a little tricky). - custom_op registrations can override each other. This makes them more pleasant to work with in environments like colab. - we require that the outputs of the custom_op do not alias any inputs or each other. We enforce this via a runtime check, but can relax this into an opcheck test if it really matters in the future. Test Plan: - new tests Pull Request resolved: pytorch#122344 Approved by: https://github.com/ezyang, https://github.com/albanD

Pull Request resolved: pytorch#123107 Approved by: https://github.com/soulitzer ghstack dependencies: pytorch#122344

This was referenced Mar 20, 2024

Add standalone tests for infer_schema #122319

Closed

Expand the types infer_schema can infer #122320

Closed

zou3519 mentioned this pull request Mar 20, 2024

infer_schema can add alias annotations when passed a list of mutated args #122343

Closed

zou3519 added the keep-going Don't stop on first failure, keep running tests until the end label Mar 20, 2024

pytorch-bot bot added ciflow/inductor module: dynamo labels Mar 20, 2024

zou3519 requested review from ezyang, albanD and soulitzer March 21, 2024 13:17

zou3519 marked this pull request as ready for review March 21, 2024 13:18

zou3519 commented Mar 21, 2024

View reviewed changes

test/test_custom_ops.py Outdated Show resolved Hide resolved

ezyang reviewed Mar 25, 2024

View reviewed changes

torch/_library/define.py Outdated Show resolved Hide resolved

ezyang reviewed Mar 25, 2024

View reviewed changes

test/test_custom_ops.py Outdated Show resolved Hide resolved

ezyang reviewed Mar 25, 2024

View reviewed changes

test/test_custom_ops.py Outdated Show resolved Hide resolved

ezyang reviewed Mar 25, 2024

View reviewed changes

test/test_custom_ops.py Outdated Show resolved Hide resolved

zou3519 requested a review from ezyang March 27, 2024 16:29

albanD reviewed Mar 27, 2024

View reviewed changes

zou3519 added 3 commits March 29, 2024 07:48

zou3519 requested a review from albanD March 29, 2024 15:21

ezyang reviewed Mar 29, 2024

View reviewed changes

torch/_library/custom_ops.py

def custom_op(

name: str,

/,

Copy link

Contributor

ezyang Mar 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aw yisss

albanD reacted with laugh emoji

ezyang approved these changes Mar 29, 2024

View reviewed changes

zou3519 mentioned this pull request Apr 1, 2024

Add mutated_args field to custom_op #123129

Closed

albanD approved these changes Apr 2, 2024

View reviewed changes

albanD reviewed Apr 2, 2024

View reviewed changes

zou3519 added ciflow/trunk Trigger trunk jobs on your pull request release notes: composability release notes category labels Apr 2, 2024

zou3519 added 2 commits April 2, 2024 08:09

pytorchmergebot closed this in 44c0c0f Apr 3, 2024

pytorchmergebot pushed a commit that referenced this pull request Apr 3, 2024

Remove mypy-ignore-errors from custom_op_db (#123107)

9aa1a4d

Pull Request resolved: #123107 Approved by: https://github.com/soulitzer ghstack dependencies: #122344

pytorchmergebot added the Merged label Apr 3, 2024

sanketpurandare pushed a commit to sanketpurandare/pytorch that referenced this pull request Apr 22, 2024

Remove mypy-ignore-errors from custom_op_db (pytorch#123107)

f5f0b1d

Pull Request resolved: pytorch#123107 Approved by: https://github.com/soulitzer ghstack dependencies: pytorch#122344

github-actions bot deleted the gh/zou3519/932/head branch May 4, 2024 01:57

		OPDEF_TO_LIB: Dict[str, "library.Library"] = {}


		def get_library_allowing_overwrite(namespace: str, name: str) -> "library.Library":



		def iter_tensors(
		args: Tuple[Any], kwargs: Dict[str, Any], allowed_nesting: int = 1

Add torch.library.custom_op #122344

Add torch.library.custom_op #122344

Conversation

zou3519 commented Mar 20, 2024 • edited by pytorch-bot bot

pytorch-bot bot commented Mar 20, 2024 • edited

🔗 Helpful Links

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

✅ No Failures

zou3519 commented Mar 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zou3519 Mar 29, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zou3519 Mar 29, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zou3519 commented Mar 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

albanD left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zou3519 commented Mar 20, 2024 •

edited by pytorch-bot bot

pytorch-bot bot commented Mar 20, 2024 •

edited

zou3519 Mar 29, 2024 •

edited

zou3519 Mar 29, 2024 •

edited