mlir

@mikeurbach and I think it would be useful to have an import/export format for scheduling problem instances, e.g. for writing test cases and benchmarking independent from the concrete (and potentially proprietary!) synthesis flow.

At its core, the problem model in CIRCT consists of a bunch of maps, indexed by MLIR operations and attributes. To that end, it seems appropriate to define a new dial

In the following IR, %optional could be replaced by %none, because the op torch.aten.arange.start implements the AllowsTypeRefinement trait. We could add a canonicalization pattern that replaces all uses by ops that allow type refinement with the operand (i.e., the more refined value).

func @aten.arange.start$int64_dtype(%start: !torch.int, %end: !torch.int) -> !torch.vtensor {

@honglh added optimized kernels for ARM32 in #432. It would be great if we could add support for bitpacked activations to them to match the AArch64 optimized bgemm kernels.

In test/create-cores/test_dma1.mlir, -aie-lower-memcpy convert

  AIE.memcpy @token0(1, 2) (%t11 : <%buf0, 0, 256>, %t22 : <%buf1, 0, 256>) : (memref<256xi32>, memref<256xi32>)
  AIE.memcpy @token1(1, 2) (%t11 : <%buf0, 0, 256>, %t33 : <%buf2, 0, 256>) : (memref<256xi32>, memref<256xi32>)

to (only shows the %t11 side)

  %2 = AIE.mem(%0) {
    %15 = AIE.dmaStart(MM2S0, ^bb1