[ONNX] Refactor _run_symbolic_function (#67573)#68491
Closed
BowenBao wants to merge 5 commits intogh/BowenBao/167/basefrom
Closed
[ONNX] Refactor _run_symbolic_function (#67573)#68491BowenBao wants to merge 5 commits intogh/BowenBao/167/basefrom
BowenBao wants to merge 5 commits intogh/BowenBao/167/basefrom
Conversation
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbao@microsoft.com> [ghstack-poisoned]
CI Flow Status⚛️ CI FlowRuleset - Version:
You can add a comment to the PR and tag @pytorchbot with the following commands: # ciflow rerun, "ciflow/default" will always be added automatically
@pytorchbot ciflow rerun
# ciflow rerun with additional labels "-l <ciflow/label_name>", which is equivalent to adding these labels manually and trigger the rerun
@pytorchbot ciflow rerun -l ciflow/scheduled -l ciflow/slowFor more information, please take a look at the CI Flow Wiki. |
Contributor
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 744c804 (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. |
This was referenced Nov 16, 2021
Member
|
@msaroufim has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> Differential Revision: [D32483782](https://our.internmc.facebook.com/intern/diff/D32483782) [ghstack-poisoned]
This was referenced Dec 7, 2021
Member
|
@msaroufim has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
BowenBao
added a commit
to BowenBao/pytorch
that referenced
this pull request
Jan 5, 2022
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> ghstack-source-id: 577a7e6 Pull Request resolved: pytorch#68491
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> Differential Revision: [D32483782](https://our.internmc.facebook.com/intern/diff/D32483782) [ghstack-poisoned]
Member
|
@msaroufim has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> Differential Revision: [D32483782](https://our.internmc.facebook.com/intern/diff/D32483782) [ghstack-poisoned]
Member
|
@msaroufim has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
BowenBao
added a commit
to BowenBao/pytorch
that referenced
this pull request
Jan 21, 2022
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> ghstack-source-id: 577a7e6 Pull Request resolved: pytorch#68491
BowenBao
added a commit
to BowenBao/pytorch
that referenced
this pull request
Jan 21, 2022
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> ghstack-source-id: 577a7e6 Pull Request resolved: pytorch#68491
BowenBao
added a commit
to BowenBao/pytorch
that referenced
this pull request
Jan 31, 2022
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> ghstack-source-id: 577a7e6 Pull Request resolved: pytorch#68491
* Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Co-authored-by: BowenBao <bowbaomicrosoft.com> Differential Revision: [D32483782](https://our.internmc.facebook.com/intern/diff/D32483782) [ghstack-poisoned]
Contributor
|
@malfet has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
facebook-github-bot
pushed a commit
that referenced
this pull request
Feb 11, 2022
Summary: Pull Request resolved: #68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com>
Contributor
|
Hey @BowenBao. |
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 15, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 15, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 15, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 16, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 16, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 17, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 20, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 20, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 20, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
cyyever
pushed a commit
to cyyever/pytorch_private
that referenced
this pull request
Feb 21, 2022
Summary: Pull Request resolved: pytorch/pytorch#68491 * Allows implementing symbolic functions for domains other than `aten`, for example `prim`, in symbolic_opset#.py. * Allows symbolic function to access extra context if needed, through `SymbolicFunctionState`. * Particularly, the `prim::PythonOp` special case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter. * `prim::Loop`, `prim::If`, etc are now moved outside of `_run_symbolic_function` from utils.py, and to symbolic_opset9.py. Motivation for this change: - Better maintainability and reducing complexity. Easier to add symbolic for operators, both simple and complex ones (that need additional context), without the former needing to know the existence of the latter. - The design idea was long outdated. prim ops are no longer rare special cases, and they shouldn't all be handled inside `_run_symbolic_function`. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signature `prim_[opname]`, creating separation and confusion. Test Plan: Imported from OSS Reviewed By: jansel Differential Revision: D32483782 Pulled By: malfet fbshipit-source-id: f9affc31b1570af30ffa6668da9375da111fd54a Co-authored-by: BowenBao <bowbao@microsoft.com> (cherry picked from commit 1e04ffd2fd1511d7d144f23afc997bf16fa1d2cc)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack from ghstack:
[ONNX] Minor doc update (#69501) #69550
[ONNX] Add Concat to Scalar type analysis JIT pass (#69227) #69548
[ONNX] De-duplicate initializers (#68202) #69547
[ONNX] Link to the wiki (#68505) #72663
-> [ONNX] Refactor _run_symbolic_function (#67573) #68491
Allows implementing symbolic functions for domains other than
aten, for exampleprim, in symbolic_opset#.py.Allows symbolic function to access extra context if needed, through
SymbolicFunctionState.prim::PythonOpspecial case can access node without the need of passing node through inputs. Updates will be made downstreams, and in a follow-up PR we will remove the previous workaround in exporter.prim::Loop,prim::If, etc are now moved outside of_run_symbolic_functionfrom utils.py, and to symbolic_opset9.py.Motivation for this change:
_run_symbolic_function. As a result this function becomes too clumsy. There were also prim ops symbolic added in symbolic_opset#.py with signatureprim_[opname], creating separation and confusion.Co-authored-by: BowenBao bowbao@microsoft.com
Differential Revision: D32483782