WIP - removeBinary

[SushmitaThakallapalli1980]

REMOVE_BINARY summary:

This RemoveBinary class is a pattern-matching and rewrite utility that finds and removes binary ops (Add, Sub, Mul, Div) in quantized ONNX graphs when one input is effectively a constant. It folds the constant into the quantization parameters instead of keeping an explicit binary op in the graph.

This class rewrites patterns like:

 Dequant(x) ----\
                             Binary(Add/Sub/Mul/Div) → Quant → Dequant
Dequant(const)-/

into something like

  Dequant'(x, new_scale/zp) → Quant → Dequant
  
  Where the constant is folded into scale or zero-point. 
  
  Then, a check is performed to see if we can possibly remove the Quant → Dequant chain.

[tvivies-amd]

I added @xiaohanAMD as reviewer too since he wrote the initial pattern and some improvements

[tvivies-amd]

A couple of small comments, I like the usage of if constexpr and the state structure.

[tvivies-amd]

Ideally you would not remove the debug ouptut that you used during the implementation, I would prefer if you could log them instead. @ehsan-toosi do you know if there is any logging capabilities in this repo ?

[tvivies-amd]

nit: add bracket here too, in order to keep the coding style consistent

[SushmitaThakallapalli1980]

ok

[tvivies-amd]

I think you can put this in the match_qdq method and return directly the output of the call to match_qdq

[tvivies-amd]

If the binary op is a qdq operation, I would expect that the output of the binOp only has one user that is the QuantizeLinear operation. This is what the python implementation is expecting and it is fine if we have the same check here

[SushmitaThakallapalli1980]

ok.

[tvivies-amd]

I wonder if we need to use the greedy approach here, since we are not creating any new ops that would needs to be visited by the pass and same for the modified ops they do not need to be matched again. See documentation of the walker configuration: https://mlir.llvm.org/docs/PatternRewriter/#walk-pattern-rewrite-driver
What do you think ?

[SushmitaThakallapalli1980]

Tried replacing applyPatternsAndFoldGreedily with walkAndApplyPatterns. But the code is crashing for some test cases. Not sure why. Therefore, restored greedy driver again.

[xiaohanAMD]

this pattern is very complicated when there is fork in the match chain. Please add test case to fix this scenario, here Q1 has a fork, we expect not to fold into DQ1, but in Q2:

        const ---\
                 |
                 v
Q1 ---> DQ1 -> BinOp -> Q2 -> DQ2
    |
    \-> something else

[SushmitaThakallapalli1980]

this pattern is very complicated when there is fork in the match chain. Please add test case to fix this scenario, here Q1 has a fork, we expect not to fold into DQ1, but in Q2:

        const ---\
                 |
                 v
Q1 ---> DQ1 -> BinOp -> Q2 -> DQ2
    |
    \-> something else

@xiaohanAMD
In the following https://jira.xilinx.com/browse/AIESW-8092, as per the initial scoping, folding is expected only on DQ1...Is this not the case?

[xiaohanAMD]

this pattern is very complicated when there is fork in the match chain. Please add test case to fix this scenario, here Q1 has a fork, we expect not to fold into DQ1, but in Q2:

        const ---\
                 |
                 v
Q1 ---> DQ1 -> BinOp -> Q2 -> DQ2
    |
    \-> something else

@xiaohanAMD In the following https://jira.xilinx.com/browse/AIESW-8092, as per the initial scoping, folding is expected only on DQ1...Is this not the case?

I didn't see that, sure, let's implement the basic in this PR. More complicate case we can do later.