[rocisa] Use comgr instead of calling amdclang++

[KKyang]

Use comgr C API instead of calling amdclang++ directly.

[hcman2]

ok if ci pass

[stellaraccident]

Let's land #1951 first since that introduces a structural improvement.

This needs more work to not leak and be exception safe and should be implemented in the helper.cpp introduced in the above.

Also, please don't land those cmake changes to rocm_path. I couldn't follow why they were needed so we can discuss more what the intent is.

[stellaraccident]

What happens if any of these get an error and throw? As I read it, every one of them leaks memory.

You need to rewrite this so that your allocated entities are contained by a raii instance that will deallocate any allocated things on destruction. See #1951 for one (of many) ways you can do this to bridge to a c based API safely.

[KKyang]

I'll change to unique_ptr instead

[stellaraccident]

I'm not sure that is a good way: these have explicit apis for create/release and do not have the same semantics as delete with respect to nullptr afaict. But I'll have a look at what you come up with.

[KKyang]

Merge after #1951 is merged

[stellaraccident]

I tested this on Windows, and indeed, we are going to need more work there. The issue is that you can't just have a cross-filesystem dep on a DLL like this (which is what a Python extension is) without making arrangements for how to find it at runtime (i.e. there is no RPATH on Windows).

ImportError: DLL load failed while importing rocisa: The specified module could not be found.

The Python frameworks solve this in one of two ways:

1. Bundle ROCm as a sibling to the Python binary distribution in a way that it can be found. PyTorch does this in the current version and it is as invasive as it sounds.
2. Use a Python level pre-loading mechanism to load the necessary DLLs prior to importing the Python extension (which links to DLLs by name). This is what CUDA based dependencies do and what ROCm based PyTorch will do in the next version.

Neither option is particularly satisfying for this kind of situation. In this case, since it is a build-only dep, we would most likely want to emulate the Linux RPATH mechanic to ensure the DLL is loaded properly. However, doing that properly will require a bit more pre-work.

Could we put this change on ice for a little while? I know roughly how to enable it but have other priorities right this minute and would like to come up with a mechanism that will work for any ROCm project vs just a one off. If this becomes urgent, I could do something project specific in a few hours if needed.

[stellaraccident]

Marking request changes per the above discussion. We can apply this once a bit more work is done on the windows side.