[Bugfix][IR][AIE] using cpp-style implicit type casting rule for aie backend

[Fangtangtang]

Description

1. updates and bugfix to be compatible with the new LLVM version updated in [Version] Bump LLVM to main (v21.1.7+) #483.
2. This PR fixes [BUG][IR][AIE] Inappropriate type casting for aie backend #484.

Problems

2. described in [BUG][IR][AIE] Inappropriate type casting for aie backend #484

Proposed Solutions

2. using cpp-style implicit type casting for aie backend.

Checklist

Please make sure to review and check all of these items:

• PR's title starts with a category (e.g. [Bugfix], [IR], [Builder], etc)
• All changes have test coverage (It would be good to provide ~2 different test cases to test the robustness of your code)
• Pass the formatting check locally
• Code is well-documented

[Fangtangtang]

Compatibility issue 1:
operations like

linalg.fill ins(%c1_i32 : i32) outs(%alloc : memref<i16>)

become invalid after llvm version update.

During construction, it now raises the following error:

ValueError: Cannot overwrite type mapping T = i32 by type i16.

According to linalg.fill dialect doc

The value operand type must match the element type of the output.

[Fangtangtang]

Compatibility issue 2:

mlir object equality check seems different. e.g., stream_put.parent is stream_get.parent is not the same as stream_put.parent == stream_get.parent

[chhzh123]

Compatibility issue 2:

mlir object equality check seems different. e.g., stream_put.parent is stream_get.parent is not the same as stream_put.parent == stream_get.parent

In this case we should use ==?

[Fangtangtang]

Compatibility issue 2:
mlir object equality check seems different. e.g., stream_put.parent is stream_get.parent is not the same as stream_put.parent == stream_get.parent

In this case we should use ==?

right

[chhzh123]

LGTM. Let me know when it is ready to merge.

[chhzh123]

Could you also help add a docstring to document what the arguments mean in this customize function?

[Fangtangtang]

ready to merge

[chhzh123]

Is this PR a replacement of #462? Can I close that one?

[Fangtangtang]

partially. It only addresses type casting issues for aie backend. Some redundant type casting in the hls backend is not handled here.
actually I’m not sure whether keeping these casts in allo IR has any performance impact for hls backend. if the backend applies sufficient optimization passes, leaving them in our IR may be fine.

I think #462 can be closed. If we do want to clean up some redundant type casting in our IR, #462 is not an elegant solution, we should consider alternative approaches.

[zhangzhiru]

Let's keep #462 open then