[JIT] SubgraphRewriter: Rename pattern fusion to subgraph rewrite.

[ZolotukhinM]

Stack from ghstack:

• [JIT] SubgraphRewriter: Add a support for arbitrary replacement graphs in subgraph rewriter. #20084 [JIT] SubgraphRewriter: Add a support for arbitrary replacement graphs in subgraph rewriter.
• [JIT] SubgraphRewriter: Expose runOnGraph and use it in tests. #20083 [JIT] SubgraphRewriter: Expose runOnGraph and use it in tests.
• [JIT] SubgraphRewriter: Rename pattern fusion to subgraph rewrite. #20082 [JIT] SubgraphRewriter: Rename pattern fusion to subgraph rewrite.

Differential Revision: D15190193

[raghuramank100]

Feature request:

We will run into cases, where we want to do more than a pattern replacement. Example: Consider replacing a dequant->conv->quant with a qconv. The weight_scale, input_scale and output_scale are nodes in the graph, which we can access directly.

We could (not at present) have a case where we will need to do a computation, requant_scale =round(output_scale/(weight_scale*input_scale)*2^k) and provide this as an input to a qconv(x,w,requant_scale) which would internally do: round(conv(xq,wq)*requant_scale>>k). How do we plan to handle cases like this? Would we have a 'pack/init_conv' op that would do the necessary pre-processing so that the required values (like requant_scale) are available in IR?

[suo]

random style nit: I think \brief makes the comment less readable. For doxygen, you can configure so the first line in a javadoc-style comment is automatically taken as the brief description anyway.

So the comment could look like

/**
 * this is the brief description.
 * This is the rest
 */

[ZolotukhinM]

We will run into cases, where we want to do more than a pattern replacement. Example: Consider replacing a dequant->conv->quant with a qconv. The weight_scale, input_scale and output_scale are nodes in the graph, which we can access directly.
We could (not at present) have a case where we will need to do a computation, requant_scale =round(output_scale/(weight_scale*input_scale)*2^k) and provide this as an input to a qconv(x,w,requant_scale) which would internally do: round(conv(xq,wq)*requant_scale>>k). How do we plan to handle cases like this? Would we have a 'pack/init_conv' op that would do the necessary pre-processing so that the required values (like requant_scale) are available in IR?

There are several options: 1) We could represent this computation directly in IR, in that case everything would just work as-is. 2) This pass is not intended to replace the entire compiler. When there is something it could not reasonably do, we always could add another pass. 3) We could add a preparation pass that would precompute these values and insert the corresponding values into IR.

In the particular case you mentioned, I think we would do (3).

[zdevito]

Assuming this is just a rename, I didn't review the code otherwise.

[facebook-github-bot]

@ZolotukhinM merged this pull request in 8a6072c.