You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we export/convert a Python function to a ModelProto, we need to identify the set of functions that will be included in the generated ModelProto as model-local functions. Furthermore, the users should be able to control this. For example, I might want to create model that calls Relu, with or without including the function-definition for Relu (even though we might have a function-definition for Relu available).
Another related feature is that of allowing potentially multiple function-definitions for the same op (in a code-base). It would be good if the underlying design enables this. It is also related to the notion of a "library" (a "LibProto" in serialized form) to represent a set of function-definitions bundled together. And to the ability to "link" a ModelProto against one or more libraries.
I suggest that we remove the embedded functions stored in the IR objects (for Stmt and Function), and instead make to_model_proto and to_graph_proto take a resolver object as a parameter, where a resolver is a dictionary-like object that, given a function-identifier (name, opset, version) returns a FunctionProto or None. The goal is to decouple the mechanism used to maintain a mapping from function-identifiers to their corresponding FunctionProto instead of hard-coding it into the IR itself. This will help address the key concerns, such as below:
The behavior of foo.to_model_proto() should be well-defined. As it exists today, assume that foo calls bar. If we do an import bar_def that has the effect of defining the body of bar, then foo_to_model_proto() will include the definition of bar as a model-local function, otherwise it won't. So, the behavior of to_model_proto ends up depending on hidden-state. It is better if the behavior is explicitly captured by an extra-parameter resolver of to_model_proto.
When we export/convert a Python function to a ModelProto, we need to identify the set of functions that will be included in the generated ModelProto as model-local functions. Furthermore, the users should be able to control this. For example, I might want to create model that calls Relu, with or without including the function-definition for Relu (even though we might have a function-definition for Relu available).
(See PR: #41 )
The text was updated successfully, but these errors were encountered: