Standardized core functions

[ypapadop-amd]

Current Assumptions

1. Core functions have external C linkage, e.g.,

   mlir-aie/aie_kernels/aie2/softmax.cc

   Line 68 in 45c368a

   extern "C" {

2. Only functions that MLIR will link against should are compiled, e.g.,

   mlir-aie/aie_kernels/aie2/mm.cc

   Line 881 in 45c368a

   #ifdef i8_i8_ONLY

3. Multiple core functions can be declared using external_func objects from the same object file, e.g.,

   mlir-aie/programming_examples/basic/matrix_multiplication/whole_array/whole_array.py

   Line 223 in 45c368a

   # AIE Core Function declarations

4. Exactly one inline function can be defined using an ExternalFunction object and associated compile time flags, e.g.,

   mlir-aie/test/python/jit_extern_functions.py

   Line 95 in 45c368a

   add_one = ExternalFunction(

5. Exactly one function in external source can be defined using an ExternalFunction object and associated compile time flags, e.g.,

   mlir-aie/test/python/jit_extern_functions_inside_jit.py

   Line 121 in 45c368a

   internal_func = ExternalFunction(

6. Exactly one object file can be linked with an MLIR module, e.g.,

   mlir-aie/python/iron/worker.py

   Line 110 in 45c368a

   if len(bin_names) > 1:

7. There is no dependency between the MLIR module generation and the core function object file. There is a dependency between MLIR module and core function object file during linking.

Pain Points

1. ExternalFunction cannot target the same object file, e.g.,

   mlir-aie/programming_examples/basic/matrix_multiplication/whole_array/whole_array.py

   Line 225 in d10d27d

   zero = external_func(f"zero{scalar_suffix}_{dtype_out_str}", inputs=[C_l1_ty])

   cannot use iron.jit for that reason without bug-prone duplication of compilation flags.
2. All code objects need to be combined to a single one. This results in complex linking situations that need to be handled in Python for JIT solutions, see Offer unsurpising build behavior #2542 and Add a code object cache for external functions #2509
3. Due to C linkage, parameter types need to encoded in the function name, e.g., softmax_bf16 instead of softmax(bfloat16_t*, bfloat16_t*, int). This encoding is not standardized leading to composition issues when one can define an IRON kernel/pattern that can be used with different core functions.

Requirements for iron.jit

1. TBD

Requirements for other integrations, e.g., JIT or build system-based approaches

1. Support for compilation flags to different source code files, e.g., for algorithm selection during compilation. [must-have]
2. Support either combining code object files or multiple code objects in MLIR modules. [must-have]
3. Calling convention standardized via C++ linkage/types. [nice-to-have]