jhuber6 added a comment. In D132248#3735943 <https://reviews.llvm.org/D132248#3735943>, @tra wrote:
> In D132248#3735900 <https://reviews.llvm.org/D132248#3735900>, @jhuber6 wrote: > >> Is this an architectural limitation? I'd imagine they'd just behave the same >> way here in my implementation. > > The constraint here is that we have to stick with a single output per > compiler invocation and that format of that output should be the same. E.g. > for C++ we'd expect to see an ELF file when we compile with `-c` and text > assembly, if we compile with `-S`. > > We could pack GPU objects into a fat binary, but for consistency it would > have to be done for single-target compilations, too. Packing a single object > into a fat binary would make little sense, but producing an object file or a > fat binary depending on the nubmer of targets would be inconsitent. > Similarly, compilation with `-S` also gets tricky -- do you bundle the text > output? That would be not particularly useful as, presumably, one would want > to examine the assembly. We could concatenate together the ASM files, but > that would produce an assembly source we can't really assemble. > On top of that, CUDA compilation has been around for a while and changing the > output format would be somewhat disruptive. > > In the end, CUDA stuck with insisting on erroring out when the `-o` has been > specified, but where it would need to produce multiple outputs. > HIP grew a `--[no-]gpu-bundle-output` option to control whether to bundle > outputs of device-only compilation. Thanks for the background. I'm assuming HIP did this because they use the old `clang-offload-bundler` which supported bundling multiple file types, while my new method relies on having some LLVM-IR to embed things in. I wasn't a huge fan of outputting bundles because it meant we couldn't do things like `clang -o - | opt` or similar. For my implementation I will probably make HIP do what CUDA does as I feel that is more reasonable unless someone has a major objection. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132248/new/ https://reviews.llvm.org/D132248 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
