pytorch

9c1a41b7 - [RFC] Add OperatorHandle overload to the RecordFunction::before() method (#46401)

[RFC] Add OperatorHandle overload to the RecordFunction::before() method (#46401) Summary: Pull Request resolved: https://github.com/pytorch/pytorch/pull/46401 Broader context about selective/custom build available at https://fb.quip.com/2oEzAR5MKqbD and https://fb.workplace.com/groups/pytorch.mobile.team/permalink/735794523641956/ Basically, we want to be able to trace full operator names (with overload name). The current observer infra picks up the operator name from the schema, which doesn't seem to include the overload name. To ensure consistency with the existing uses and to accomodate the new use-case, this diff adds a new overload to accept an `OperatorHandle` object, and the code in `before()` eagerly resolves it to an `OperatorName` object (which can be cached in a member variable) as well as a string (view) operator-name which has the same semantics as before. Why do we pass in an `OperatorHandle` but then resolve it to an `OperatorName`? This might come across as a strange design choice (and it is), but it is grounded in practicality. It is not reasonable to cache an `OperatorHandle` object but caching an `OperatorName` object is reasonable since it holds all the data itself. An initial version of this change was trying to test this change in the `xplat` repo, which didn't work. Thanks to ilia-cher for pointing out that the dispatcher observing mechanism is disabled under a compile time flag (macro) for xplat. ghstack-source-id: 114360747 Test Plan: `buck test fbcode/caffe2/fb/test:record_function_test` succeeds. Also replicated this test in OSS in the file `test_misc.cpp` where the rest of the `RecordFunction` subsystem is being tested. Ran benchmark as reqiested by ilia-cher {P146511280} Reviewed By: ilia-cher Differential Revision: D24315241 fbshipit-source-id: 239f3081e6aa2e26c3021a7dd61f328b723b03d9