graph: backend: dnnl: backend refactor of adding fusion info attr

[xiang1guo]

Background

Preliminary work for MFDNN-13442. The main purpose of this PR is to bind the fusion_info as an attribute directly onto the op, rather than using a fusion_info_key to reference a container(currently a vector store in fusion_info_mgr) that manages the fusion info.

Works

• Add new fusion_info attr.
• Update all op's attr with new attr
• Gtest update
• rename fusion_info_mgr_t to reflect the updated function

[ElaineBao]

If it's not used, shall we mark it as = delete?

[xiang1guo]

We cannot mark it as delete because this is called in attribute_value_t for comparison purpose (code). Namely all attribute should define == operator. And the operator == in attribute_value_t is actually called here in op.hpp for comparison. Since fusion_info_t is an internal attribute, it won't be used for comparison, thus I just implemented a rough one to make compiler happy(no compiation issue)

[TaoLv]

what do we need to extend?

[xiang1guo]

Oh, the extend I mentioned refers to the future scenario where we need to compare internal attributes. In that case, it would be necessary to strictly compare all the member meta ops within the fusion info.

[TaoLv]

What's the potential effort if we want to complete the comparison function here?

[xiang1guo]

Not much, it just looks a bit redundant. I had already written it down, but I thought it was too messy, so I didn't put it in current PR. :) I will add that later.

[xiang1guo]

I have added two new commits: the first one is related to the operator ==, and the second one involves cleaning up redundant code discovered while reviewing subgraph_info_mgr.

[ElaineBao]

How about directly saving these info in the subgraph_t class?

[xiang1guo]

I was thinking about this, and I think it's doable, but I didn't do that because:

1. Those subgraph info is used in op_executable when creating desc, see here. I feel passing a cleaner sungraph_info instead of full subgraph_t is clearer and simpler.
2. This involves too much change, and the first thing I want to do is just split fusion_info from this mgr to serve for compressed SDPA support.
   cc @TaoLv any suggestions?

[TaoLv]

I see there are only two extra flags: fpmath and use block layout. Is it possible to move them along with fusion info? I know these are applied graph-wise. But eventually it's used by each op and each primitive. It also seems to simplify the logic around.

[xiang1guo]

I see there are only two extra flags: fpmath and use block layout. Is it possible to move them along with fusion info? I know these are applied graph-wise. But eventually it's used by each op and each primitive. It also seems to simplify the logic around.

ok, I will take a look at this suggestion.

[xiang1guo]

I choose to save fpmath_t and block layout info in subgraph currently and pass that info to op_executable and layout_propagayor independently, please refer to the last commit and review again. Thanks!
BTW, bind these info to op fusion_info level can be a long-term plan and depends on real scenario usage as the change involves too much change now(transformation pass handling is not straightforward after I look into the implementation) :)

[xiang1guo]

make test
set test_scope=NIGHTLY
disable benchdnn_all
enable benchdnn_graph