Exactly as @larryliu0820 mentioned, I think in the case of adding operators to the ATen library that can potentially impact the core ATen opset, the core ATen opset should not block additions to the ATen library. In my view, the core ATen opset is a separate system that “tracks” the ATen library (or more specifically, the operators used in PyTorch programs) so it is the responsibility of the maintainers of the core ATen opset to respond to such changes in the ATen library.
Related topics
Topic | Replies | Views | Activity | |
---|---|---|---|---|
Defining the Core ATen Opset | 12 | 5853 | August 21, 2024 | |
PrimTorch: How backend/compiler writers interact with various IRs | 2 | 2300 | April 11, 2023 | |
Set of ops for a backend to register | 10 | 2366 | March 10, 2023 | |
PrimTorch: could we get pure core-aten-ops or prims-ops after aot_autograd | 6 | 4633 | March 21, 2023 | |
State of PyTorch core: September 2021 edition | 1 | 9405 | September 21, 2021 |