[all-commits] [llvm/llvm-project] b16f76: [LinkerWrapper] Accept some needed lld-link linker...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b16f765d6fec56a07aecd2056bb1760a9e72d64f
      https://github.com/llvm/llvm-project/commit/b16f765d6fec56a07aecd2056bb1760a9e72d64f
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2023-11-22 (Wed, 22 Nov 2023)

  Changed paths:
    M clang/test/Driver/linker-wrapper.c
    M clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
    M clang/tools/clang-linker-wrapper/LinkerWrapperOpts.td

  Log Message:
  -----------
  [LinkerWrapper] Accept some needed lld-link linker arguments for COFF targets (#72889)

Summary:
The linker wrapper is a utility used to create offloading programs from
single-source offloading languages such as OpenMP or CUDA. This is done
by embedding device code into the host object, then feeding it into the
linker wrapper which extracts the accelerator object files, links them,
then wraps them in registration code for the target  runtime. This
previously has only worked in Linux / ELF platforms.

This patch attempts to hand Windows / COFF inputs by also accepting COFF
forms of certain linker arguments we use internally. The important
arguments are library search paths, so we can identify libraries which
may contain device code, libraries themselves, and the output name used
for intermediate output.

I am not intimately familiar with the semantics here for the semantics
in how a `lib` file is earched. I am simply treating `foo.lib` as the
GNU equivalent `-l:foo.lib` in the search logic. Similarly, I am
assuming that static libraries will be llvm-ar style libraries. I will
need to investigate the actual deficiencies later, but this should be a
good starting point along with
https://github.com/llvm/llvm-project/pull/72697