Improvements to JIT workflow

[mawad-amd]

PR #2201 added JIT compilation workflows to IRON and some future improvements and suggestions are below. This issue is the umbrella issue for other future sub-tasks.

• Better syntax for launching deferred placement IRON kernels (See: Add IRON single-source Python enablement modules #2201 (comment))
• Improvements to aiecc.py to facilitate using the Python module and redirecting outputs to specific locations (See: Add IRON single-source Python enablement modules #2201 (comment))
• Automatically detecting the device and not requiring users to specify them (see: Add IRON single-source Python enablement modules #2201 (comment))
• Better/consistent naming for implicit/deferred placement (See: Add IRON single-source Python enablement modules #2201 (comment))
• Control over where the JIT-compiled binaries are stored (See: Add IRON single-source Python enablement modules #2201 (comment))
• Add tracing support Add trace with JIT example #2541

[ypapadop-amd]

One thing that #2201 has removed is an easy way to do offline compilation of kernels. E.g., before I would pick up the vector_vector_add.py and dig through the makefiles to figure out how to generate an xclbin and then use it directly w/ XRT in my application. Now this is not possible.

[jgmelber]

One thing that #2201 has removed is an easy way to do offline compilation of kernels. E.g., before I would pick up the vector_vector_add.py and dig through the makefiles to figure out how to generate an xclbin and then use it directly w/ XRT in my application. Now this is not possible.

Yes, that is a good point. This is why the plan will be to keep some examples with the Makefiles and bare XRT C++ around.

[ypapadop-amd]

I think that having the same example working with two drivers (Python and C++) in the same directory would make it clear how to transition from one to the other.

[mawad-amd]

I will add an example that showcases both approaches. Any preference on which example? I plan to iron out the deferred placement comments first before touching other code.

[jgmelber]

GEMM for sure should have all approaches since that is a design that might be integrated into a variety of frameworks. Up for suggestions on another

[ypapadop-amd]

The other thing is the pyxrt dependency in the JIT path. I think we need the launch mode as it is for the single-source, but we may need something like @iron.jit(launch=False, generate=iron.PDI) so that it generates PDIs/insts instead of xclbin and avoid the pyxrt path altogether.

You can import libraries inside a function, so we can defer loading pyxrt unless we really need to launch something. We can bikeshed the names, but that's kind of the main functionality that is missing for using it with solutions that want to control dispatch.

[jgmelber]

Good points @ypapadop-amd. I agree we want to have the JIT path be flexible, I'd also like to be able to support JIT in C++. This will require porting functionality from aiecc.py to a C++ library. That should help extend the reach of this functionality to additional frameworks.

[jgmelber]

• Automatically detecting the device and not requiring users to specify them (see: Add IRON single-source Python enablement modules #2201 (comment))

#2226 partially addresses this