Adding type constraints for aievec::mul_elem operation

[muradq-amd]

• The previous PR was automatically closed when I tried to hard rest my branch to revert unwanted changes in the [platform/boards] submodule. Here is the link to the previous PR for reference:
  • Improve type constraints for AIEVec_MulElemOp #1487.
• I rewrote the type constraints for the aievec::mul_elem operation in a simpler way, as we discussed in the last meeting.
• Changes:
  • Use operand type constraints for lhs, rhs, and acc.
  • Use already implemented predicates in:
    • llvm-project/mlir/include/mlir/IR/OpBase.td
    • llvm-project/mlir/include/mlir/IR/CommonTypeConstraints.td
• Added Constraints:
  • lhs and rhs operands must match shape.
  • lhs and rhs operands must match type.
  • IsValidAccTypeForAIE2MulElem.

Please let me know if there is a better way to revise these changes.

[jamestcl-amd]

We should just have:

        `vector<32xi8>`    | `vector<32xi8>`    | `vector<32xi32>`
        `vector<32xi16>`   | `vector<32xi16>`   | `vector<32xi32>`
        `vector<16xi32>`   | `vector<16xi32>`   | `vector<16xi64>`
        `vector<16xbf16>`  | `vector<16xbf16>`  | `vector<16xf32>`
        `vector<16xf32>`   | `vector<16xf32>`   | `vector<16xf32>`

These operations refer to the following intrinsics in the table at https://www.xilinx.com/htmldocs/xilinx2023_2/aiengine_ml_intrinsics/intrinsics/group__intr__gpvectorop__mul.html.

8-bit x 8-bit = 32-bit,	32,	1x2,	2x1,	1x1
16-bit x 16-bit = 32-bit,	32,	1x1,	1x1,	1x1
bfloat16 x bfloat16 = fp32,	16,	1x2,	2x1,	1x1

The two more are at https://www.xilinx.com/htmldocs/xilinx2023_2/aiengine_ml_intrinsics/intrinsics/group__intr__gpvectorop__emul__32bx32b.html#gae6f04990833f0cf4b62bf1433ac11e6a and
https://www.xilinx.com/htmldocs/xilinx2023_2/aiengine_ml_intrinsics/intrinsics/group__intr__gpvectorop__mul__fp32xfp32.html#gac1e9a132ee05edf8b6afe9c985598768

We can support arith.muli/arith.mulf in different result types (as you listed above), because we add aievec.cast/aievec.srs to cast the acc types back to normal integer/floating types. However, that shouldn't be part of the semantic of aievec.mul_elem.

[jsetoain]

An equivalent predicate exists upstream already.

[jsetoain]

Notice James' commit above.

[jsetoain]

Not very descriptive of what's being checked.