This is an archive of the discontinued LLVM Phabricator instance.

[clang][AIX] Enable LTO and teach the driver to pass options to the plugin
AbandonedPublic

Authored by daltenty on Feb 6 2022, 11:27 PM.

Details

Summary

This is a follow on to D119107. AIX ld now supports libLTO loaded
as a plugin

This change teaches the clang driver how to pass AIX ld the
libLTO path and the option to pass LTO significant driver options
through to the plugin. Some remarks plugin options are mapped
to their libLTO equivalents when using the AIX ld.

We need also to indicate to the toolchain that we now support
bitcode in the linker, or we run into asserts on some single-step
LTO invocations.

See also https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command for
the linker interface.

co-authored-by: Ettore Tiotto <etiotto@ca.ibm.com>
co-authored-by: Wai Hung Tsang <whitneyt@ca.ibm.com>

Diff Detail

Event Timeline

daltenty created this revision.Feb 6 2022, 11:27 PM
daltenty requested review of this revision.Feb 6 2022, 11:27 PM
daltenty edited the summary of this revision. (Show Details)
ormris removed a subscriber: ormris.Feb 7 2022, 10:31 AM
Whitney added inline comments.Feb 8 2022, 5:23 PM
clang/lib/Driver/ToolChains/CommonArgs.cpp
522

Do you think this can be more clear?

#if defined(_WIN32)
    const char *Suffix = ".dll";
#elif defined(__APPLE__)
    const char *Suffix = ".dylib";
#else
    const char *Suffix = ".so";
#endif
  SmallString<1024> Plugin;
  if (LTOPluginType == ToolChain::LTOPluginType::LTOPT_LLVMlto_AIX) {
    llvm::sys::path::native("-bplugin:" + Twine(D.Dir) +
                                  "/../lib" CLANG_LIBDIR_SUFFIX "/libLTO" +
                                  Suffix,
                              Plugin);
  } else if (LTOPluginType == ToolChain::LTOPluginType::LTOPT_LLVMgold) {
      // Tell the linker to load the plugin. This has to come before
      // AddLinkerInputs as gold requires -plugin to come before any -plugin-opt
      // that -Wl might forward.
      CmdArgs.push_back("-plugin");

      llvm::sys::path::native(
          Twine(D.Dir) + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" + Suffix,
          Plugin);
  }
daltenty added inline comments.Feb 15 2022, 7:41 AM
clang/lib/Driver/ToolChains/CommonArgs.cpp
522

Thanks, I like this simplification. I'll update with it.

daltenty updated this revision to Diff 409147.Feb 15 2022, 9:19 PM
  • Rebase
  • incorporate suggestion from review
  • add fuse-ld=ld to debugger tuning test, to make it invariant when running on platforms that might use ldd by default
daltenty updated this revision to Diff 409246.Feb 16 2022, 7:33 AM

Add back in CmdArgs.push_back(Args.MakeArgString(Plugin)) that got accidentally removed

I don't have any other comments other than those clang-format ones.

daltenty updated this revision to Diff 411475.Feb 25 2022, 11:27 AM

clang-format

daltenty updated this revision to Diff 411508.Feb 25 2022, 1:05 PM

clang-format

w2yehia added inline comments.Feb 25 2022, 2:23 PM
clang/lib/Driver/ToolChain.cpp
641

instead of having two functions: getLTOPluginType and getLTOPluginTypeImpl, why not just have one: getLTOPluginTypeImpl.
In the base class (ToolChain) implementation it returns LTOPT_LLVMldlld or LTOPT_LLVMgold, and then derived classes that cannot incorporate their logic into the base implementation wud override (so AIX will do that).

Right now the base class's implementation is split between getLTOPluginType and getLTOPluginTypeImpl, but is avoidable.

clang/test/Driver/lto.c
56

we don't expect any prefix other than so, no?

daltenty added inline comments.Feb 25 2022, 3:12 PM
clang/lib/Driver/ToolChain.cpp
641

Hmm, I was originally thinking the same thing. But I think the reason we need this is there's really two parts to the plugin determination:

  • a platform independent part that can determine the proper plugin if we can identify the linker by name (i.e. lld). This should be common for all platforms including AIX (one could legitimately use -fuse-ld=lld even on AIX)
  • then if we can't identify the linker by name (i.e. it's just ld), a platform specific fallback

I think we could rename getLTOPluginTypeImpl() to something like getLdLTOPluginType() and add a comment to that effect.

clang/test/Driver/lto.c
56

For the actual plugin on AIX, yes. The test however will still run other platforms, so it may encounter the other cases.

LGTM

clang/lib/Driver/ToolChain.cpp
641

makes sense

clang/test/Driver/lto.c
56

Does the -target option affect what toolchain clang uses/assumes? If it assumes the host toolchain, then yes the filetype can be non-so but then the option name -bplugin won't work. If it assumes the target toolchain, then the problem is that host toolchain might have a different interface than the target toolchain.
I realize that cross compiling is hard in general (system headers and libraries), so I'm not sure if clang needs to be spot on here. Disabling the test on non-AIX makes more sense than having a test that asserts invalid behaviour.

amyk added a comment.Mar 8 2022, 7:18 AM

Thanks for adding this David, I think this makes sense and LGTM, too.

Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2022, 7:18 AM
daltenty abandoned this revision.Oct 13 2022, 8:35 AM

We've rolled the tests added by this into https://reviews.llvm.org/D135885 instead, so abandoning this.