TargetModel in python bindings

[fifield]

I thought it would be useful to query TargetModel from python, for things like L1 size and number of columns.

>>> from aie.dialects.aie import AIEDevice, get_target_model
>>> get_target_model(AIEDevice.npu1_3col).columns()
3

@makslevental this has some overlap with PybindTypes.cpp used in the python pass stuff, so ultimately maybe there is a better way to do this. But this is one way I found to make it work.

[stephenneuendorffer]

Awesome! I've been wanting this!

[makslevental]

You can't do this. Well you can't do this and not run afoul of the RTTI constraints imposed by IREE and such - namely that there be no RTTI anywhere except the bindings modules. Lest you imagine that that is what you have here, I encourage you to try to build in no_rtti mode as we do here https://github.com/Xilinx/mlir-aie/blob/main/.github/workflows/mlirAIEDistro.yml#L103.

You also can't do this because you're not actually linking the dialect libs and either getting lucky that the right code ends up in the AggregateCAPI lib or not (currently the tests fail).

Much more information here and here.

In summary: there's a reason why the PybindTypes stuff is behind a build flag and also the CMake around there is "black magic".

EDIT:

Indeed the fails are due to missing symbols

ImportError: /home/runner/work/mlir-aie/mlir-aie/build_assert/python/aie/_mlir_libs/_aie.cpython-38-x86_64-linux-gnu.so:
 undefined symbol: _ZTVN6xilinx3AIE14AIETargetModelE
FileCheck error: '<stdin>' is empty.

[jgmelber]

You can't do this. Well you can't do this and not run afoul of the RTTI constraints imposed by IREE and such - namely that there be no RTTI anywhere except the bindings modules. Lest you imagine that that is what you have here, I encourage you to try to build in no_rtti mode as we do here https://github.com/Xilinx/mlir-aie/blob/main/.github/workflows/mlirAIEDistro.yml#L103.

You also can't do this because you're not actually linking the dialect libs and either getting lucky that the right code ends up in the AggregateCAPI lib or not (currently the tests fail).

Much more information here and here.

In summary: there's a reason why the PybindTypes stuff is behind a build flag and also the CMake around there is "black magic".

EDIT:

Indeed the fails are due to missing symbols

ImportError: /home/runner/work/mlir-aie/mlir-aie/build_assert/python/aie/_mlir_libs/_aie.cpython-38-x86_64-linux-gnu.so:
 undefined symbol: _ZTVN6xilinx3AIE14AIETargetModelE
FileCheck error: '<stdin>' is empty.

Is there a better way to do this that you can suggest @makslevental ?

[makslevental]

Is there a better way to do this that you can suggest @makslevental ?

Jeff got it - you just have to plumb everything through a C API.

[stephenneuendorffer]

I think this is not a good idea... My intention with the TargetModel is that it's a singleton pattern, which is independent of the MLIR. an AIEDevice is the device of a particular design. And a Device is not actually necessary, only a container object that implements the right interface. It's unclear to me why you need to walk from the TargetModel back to a device anyway?

[fifield]

It was convenient for wrapping/unwrapping to keep only the enum around, and this helped with that. https://github.com/Xilinx/mlir-aie/pull/1500/files#diff-3f51e6951752378031f1f22e2616b9d3c77de3a54fcbb31cdc6ab6bd34d109dbR18-R24. But I can probably refactor to avoid the change to TargetModel