This patch adds the support to create a job for the OffloadBundlingAction which will invoke the clang-offload-bundler tool.
Sorry about the years-later question, but what's the motivation for shelling out to an external command here? In general, LLVM tries to use a library-based approach, and LLVM went e.g. through great lengths do use an integrated assembler so clang doesn't have to shell out to one. Concretely, why isn't there a clang/lib/OffloadBundle library that clang and clang-offload-bundler both use? Does the bundling have to happen out-of-process? And if so, why isn't the process something like clang -cc1bundle instead of a separate executable? It seems weird to make clang depend on another executable next to it.
I apologize for the clueless question.
@thakis, I don't think there is anything preventing the bundler from being driven by clang and implemented in a library. The discussions about the bundler were mostly around the bundling formats - so where it should be implemented was not as thoroughly discussed as the the formats we ended up adopting. Notwithstanding, there were a few reasons that motivated the current design:
- The bundler should have a driver: users/developers should be able to easily pack/unpack the pieces referring to different devices. It could be a clang -cc1bundle though.
- Offloading with many targets and different host/target combinations would require a myriad of formats that need to be used together, so they were some informal discussions where people seemed to prefer to separate this complexity from clang itself. The bundler would need some dependencies to handle object files that were not needed by clang (at least at the time).
- The main use of the bundler is the bundling/unbundling of object files which were produced by third party tools (e.g. NVIDIA tools), so there was not a clear advantage in integrating the bundler as a library, as one needs to spawn a separate process to create its dependences anyway.