pytorch

5d7b2089 - Draft version: Make AliasAnalysisKind optional in Op Registration API (#30187)

Draft version: Make AliasAnalysisKind optional in Op Registration API (#30187) Summary: Don't look into deep into the diff's implementation. The reason to send out this diff is to help sync on the design first. Once we agree on the design, I will update the implementation accordingly. **Here is the basic design for achieving this functionality:** **Q1: Do we need to tell apart case between the following:** case 1: registry 1: PURE -> registry 2: CONSERVATIVE case 2: registry 1: PURE -> registry 2: <not set> A: should be yes though, right now both cases have same value(due to defaulting to CONSERVATIVE) in operators_ and operatorLookupTable_. case 1 should be denied while case 2 should be legal case where registry 1 will be PURE at the end. **How to tell apart both cases:** Right now, AliasAnalysisKind::CONSERVATIVE is by default (code pointer: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/fbcode/caffe2/aten/src/ATen/core/dispatch/OperatorOptions.h?lines=22%2C52) Current approach: Introducing a boolean flag in OperatorOptions called isDefault, defaulting to value true. When manually call setAliasAnalysis(AliasAnalysisKind), it will be set too false. And then when findSchema() in Dispatcher.cpp, we will check response's option's isDefault value. If isDefault = true, then with some sanity check and if all checks passed, we can update the option info in both operators_ and operatorLookupTable_ Other approaches: 1. Introducing a new AliasAnalaysisKind maybe called NOT_SPECIFIED. (I am not doing it this way since then I need to update other callosities related to AliasAnalaysisKind::CONSERVATIVE) Also, we will need to have additional logics to align between NOT_SPECIFIED and CONSERVATIVE **What data to be updated:** corresponding entry in std::list<OperatorDef> operators_ and LeftRight<ska::flat_hash_map<OperatorName, OperatorHandle>> operatorLookupTable_ (More things to be discussed here.) **Do we need to trigger listeners if an entry get updated:** I think no. callOnOperatorRegistered(op) seems only to be using OperatorHandle.schema now from the only callsite from register_c10_ops.cpp (code pointers: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/fbcode/caffe2/aten/src/ATen/core/dispatch/Dispatcher.cpp?commit=b4cefeaa98dca5b1ec5f7a0bca6028e368960244&lines=87-90 and https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/fbcode/caffe2/torch/csrc/jit/register_c10_ops.cpp?lines=178&link_ref=biggrep) However, things can be much more complicated if future extensions may use options when some listeners want to use options value to register operators. **Future reading list + remaining questions:** 1. How options get consumed on the other side. 2. Usages for fields in OperatorEntry besides schema/options/kernals Pull Request resolved: https://github.com/pytorch/pytorch/pull/30187 Test Plan: [xintchen@devvm6308.prn2 ~/fbsource/fbcode] buck test mode/dev //caffe2:ATen-core-test All tests passed Differential Revision: D18530964 Pulled By: charliechen0401 fbshipit-source-id: 60c0560a63a36e54f09f397667bb7122b61d6a8e