[PATCH] Always add LLVMgold.so plugin if it's present in the standard location

[Tom Roeder]

On Tue, Feb 18, 2014 at 12:01 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 18 February 2014 14:25, Tom Roeder <tmroeder at google.com> wrote:
>> The attached patch changes the behavior of the driver to always add
>> LLVMgold.so if it can find it in ../lib/LLVMgold.so. This is the
>> location it was already using if the -flto flag was passed.
>>
>> The goal here is to make it easier to apply -flto in large codebases
>> containing multiple projects. E.g., when I was working on building
>> Chromium with LTO, one of the problems I encountered is that some
>> projects would end up depending on files that had been built as
>> bitcode. And these projects then needed to be modified to add -flto so
>> they could use the bitcode files. It seems natural, at least to me,
>> that clang should be able to handle .o or .a files that are bitcode
>> without requiring -flto explicitly.
>>
>> This is my first patch sent to cfe-commits, and I don't know the clang
>> part of the codebase as well as the LLVM bits, so please let me know
>> if I'm missing something here. I thought it was going to be more
>> complicated to change this behavior, and I find it hard to believe
>> that it's quite as simple as this patch makes it seem.
>
> The idea is interesting, but there are two potential issues:
>
> What will bfd ld and gold do with -plugin if they are compiled without
> plugin support? Error or just ignore the option? If error, how common
> is it for distros to build them without plugin support?

Yeah, it looks like ld errors if it's given a bad option. So, having
this as the default won't work smoothly in all cases.

What if this were hidden behind a build flag that defaulted to OFF?
I.e., you can choose to build a version of clang that always passes
gold to ld, but the default would stay the way it currently is.

>
> What is the performance impact of passing -plugin when no LTO is being done?

This is a good question, and I'm going to try it out on some large
codebases soon.

Tom