[libclc] [llvm] [libclc] Support LLVM_ENABLE_RUNTIMES when building (PR #141574)

[Fraser Cormack via cfe-commits]

frasercrmck wrote:

> > That said, I don't believe it "works" in the way it's supposed to. It still grabs the host tools using `get_host_tool_path` in CMake, and custom commands to build with that. I take it we're supposed to use `CMAKE_C_COMPILER` as if we were a regular CMake project? Are we able to use `opt` and `llvm-link` and other LLVM tools?
> 
> Yes, the whole point is that we can use `add_library` instead of custom commands. You can still find those tools and use them if necessary however. For that you'd want to emit an object library and then add a custom command that uses all the generated objects to link / opt them and finally output them. OpenMP's GPU runtime used to do that but I hacked around it with LTO stuff.

I'll need to look into that - maybe we can talk offline. Since `libclc` is used by downstream toolchains I feel it'll be hard to significantly change how it's built or presented to the host. We could support two methods of building but that would get sticky pretty quickly.

> Yeah, something like `LIBCLC_TARGETS_TO_BUILD` is likely what should be implied by the `LLVM_DEFAULT_TARGET_TRIPLE` value that the runtimes build passes in. (Also, does amdgcn-amd-amdhsa not work? That's the canonical one).

I'm not sure about how best to deal with `LIBCLC_TARGETS_TO_BUILD`. It could also pick up from `LLVM_TARGETS_TO_BUILD` but we have targets like `clspv` and `clspv64` which don't conveniently match any LLVM triple and are used by a downstream.

I'm not sure about how the AMD triples work, perhaps @arsenm can answer that. I know that downstream we're changing the final bytecode library to `amdgcn-amd-amdhsa` - perhaps for a similar reason.

> It's an external project, it uses the same handling. You can do `ninja -C ./runtimes/runtimes-<triple>-bins` and it will behave the same.

Ah yes, thank you :+1:.


https://github.com/llvm/llvm-project/pull/141574