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

Mon May 23 11:50:18 PDT 2022

jhuber6 added a comment.

In D126226#3532127 <https://reviews.llvm.org/D126226#3532127>, @tra wrote:

> `-Xoffload-linker=<triple> <arg>`
>
> The syntax is confusing. Normally only `triple` would be the argument for `-Xoffload-linker` option. 
> Having both `-Xoffload-linker` and `-Xoffload-linker=` variants also looks odd to me.
>
> In effect you're making `-Xoffload-linker=foo` a full option (as opposed to it being an option `-Xoffload-linker= ` + argument `foo`) with a separate argument that follows. I guess that might work, but it's a rather unconventional use of command line parser, IMO.
>
> I think the main issue with this approach is that it makes the command line hard to understand. When one sees `-Xsomething=a -b` it's impossible to tell whether `-b` is a regular option or something to be passed to `-Xsomething=a`. My assumption would be the former as `-Xsomething=` already got its argument `a` and should have no business grabbing the next one.
>
> I think it would work better if the option could use a `-` or`_` for the variant that passes the triple. E.g. `-Xoffload-linker-nvptx64=-foo`  or `-Xoffload-linker-nvptx64 -foo` would be easily interpretable.

We already use this approach for the `-Xopenmp-targets=<triple> <arg>` option that forwards arguments to the given toolchain, so that's what I was using as a basis. I'm not sure if I want to hard-code the triple value into the argument itself, since this could theoretically be used for any number of triples, e.g. OpenMP offloading to `ppcle64` and `x86_64`, so it would get a little messy. It's definitely a bit harder to read, but it's a bit of a special-case option so it's to be expected I think.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126226