[PATCH] D126226: [OpenMP] Add `-Xoffload-linker` to forward input to the device linker

Artem Belevich via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon May 23 14:40:20 PDT 2022


tra added a comment.

In D126226#3532471 <https://reviews.llvm.org/D126226#3532471>, @jhuber6 wrote:

> In D126226#3532423 <https://reviews.llvm.org/D126226#3532423>, @tra wrote:
>
>> We keep running into the same old underlying issue that we do not have a good way to name/reference specific parts of the compilation pipeline. -Xfoo used to work OK for the linear 'standard' compilation pipeline, but these days when compilation grew from a simple linear pipe it's no longer adequate and we need to extend it.
>
> Yeah, it's getting increasingly complicated to refer to certain portions of the compilation toolchain as we start adding more complicated stuff. Just recently I had a problem that I wanted to pass an `-Xclang` argument only to the CUDA toolchain, and there's no way to do it as far as I can tell. It may be worth revisiting this whole concept to support more arbitrary combinations.

`-Xarch_device` should do that for all device compilations, or you could use `-Xarch_sm_XX` if you need to pass it only to the compilation targeting `sm_XX`.

>> Speaking of triples. I think using triple as the selector is insufficient for general offloading use.
>
> Yes, it's not a truly generic solution. But I figured that just being able to specify it for each "tool-chain" was sufficient for the use-case here and we can expand it as needed. I added support for OpenMP to use `--offload-arch` recently so we definitely use it. The OpenMP offloading GPU runtime library is now built as a static library with `--offload-arch=` for all 32 supported architectures currently, it works surprisingly well.

The comment was largely intended as a counterargument to @MaskRay 's proposal to hardcode triples into arguments. It's doable, but with ever continuing expanding set of offloading targets will be the source of unnecessary churn. It it were just triples, it would be fine, but our set is potentially a cartesian product of {triple, GPU variant} and both AMDGPU and nvptx have quite a few GPU variants they can target.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126226/new/

https://reviews.llvm.org/D126226



More information about the cfe-commits mailing list