[PATCH] D29445: LTO: add a code-model flag

[Martell Malone via Phabricator via llvm-commits]

martell added a subscriber: rafael.
martell added a comment.

In https://reviews.llvm.org/D29445#670264, @pcc wrote:

> > I think I am missing something here. How does `Config->CodeModel = CMModel;` get all the way into the gold plugin for parsing.  I had to add an option to `process_plugin_option` to pull out the string.
>
> In the gold plugin any options that the plugin does not recognize are passed through to `cl::ParseCommandLineOptions`, see http://llvm-cs.pcc.me.uk/tools/gold/gold-plugin.cpp#234
>
> > Is there something within `cl::opt` that has the magic to check the string against CMModel?
>
> Yes, any `cl::opt`s of enum type are checked during `ParseCommandLineOptions`. The command line library will produce an error message if the option string does not match any of the enumerators.


Great thanks for clearing that up @pcc
@rafael your message to the thread never ended up on phab, I didn't miss it though I added a gold testcase as you asked. The StringSwitch should not be necessary though if we use CommandFlags.

Using `CommandFlags.h` seems to create a conflict because it is included in `LTO.cpp` in lld also.
Ignoring the issue of `Target` being ambitious which is easily solved by specifying the `lld::elf` type, the link time error for duplicate symbols is not.

  lib/liblldELF.a(LTO.cpp.o):(.bss._Z7ABINameB5cxx11+0x0): multiple definition of `ABIName[abi:cxx11]'
  lib/liblldELF.a(Driver.cpp.o):(.bss._Z7ABINameB5cxx11+0x0): first defined here

What would be the suggested path here.
Moving `createLTO` into `Driver.cpp` does not seem like an ideal solution to me?


Repository:
  rL LLVM

https://reviews.llvm.org/D29445