[PATCH] D20423: [Clang][LLVMGold] Passing LLVM arguments to gold plugin

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Tue May 31 15:02:42 PDT 2016


> On 2016-May-31, at 14:52, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On May 31, 2016, at 2:50 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> 
>>> On 2016-May-31, at 11:01, Teresa Johnson <tejohnson at google.com> wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 31, 2016 at 10:12 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>> 
>>>> On May 31, 2016, at 10:06 AM, Teresa Johnson <tejohnson at google.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Tue, May 31, 2016 at 10:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>> 
>>>>> On May 31, 2016, at 10:00 AM, Teresa Johnson <tejohnson at google.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, May 31, 2016 at 9:47 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>>> 
>>>>>> On May 31, 2016, at 9:42 AM, Teresa Johnson <tejohnson at google.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, May 24, 2016 at 4:01 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>>>> This seems strange to me.  For example, it breaks the otherwise very convenient:
>>>>>> --
>>>>>> $ clang -flto t.c -mllvm -some-internal-option-for-cc1
>>>>>> --
>>>>>> 
>>>>>> What is an example mllvm option that is passed to cc1 that would be illegal to pass via the gold-plugin - it isn't just ignored?
>>>>> 
>>>>> I believe it is not about being "illegal" but rather being surprised by some unintended behavior, and losing the ability to control what options is applied during link compared to the cc1-optimizations phase.
>>>>> 
>>>>> But if I did a vanilla -O2 build and passed -mllvm it would be passed down to the optimization pipeline. I find the reverse (it isn't when I do -O2 -flto) more surprising.
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I don't understand how it's better.
>>>>>> 
>>>>>> Another issue with the current situation is that in order to pass these to llvm in LTO builds (at least for gold) you have to do -Wl,-plugin-opt,-mllvm,-some-option, and gold gives a fatal error if it sees a -plugin-opt without -plugin. So for example in a clang LTO bootstrap I cannot set it up to pass any -mllvm option via plugin-opt because there are link steps that create intermediate shared libraries but don't invoke the plugin, so I get a fatal error (this affects all plugin-opt, but -mllvm is probably a likely one that I would want to pass for debugging or analysis).
>>>>> 
>>>>> I'm surprised that you are building intermediate shared library during a bootstrap of clang, and even more that they're not built out of bitcode?
>>>>> 
>>>>> Looks like it is compiler-rt asan code (libclang_rt.asan-i386.so) that is not being built with LTO, which I think makes sense given that it is linked into user code not into the compiler.
>>>> 
>>>> I didn't mean to have a .so that is itself bitcode (that should never happens: it does not make sense), but rather that the .so is built out of bitcode files.
>>>> 
>>>> Confirmed that the compiler-rt files are native .o files -  Do I need to do something special to get LLVM_ENABLE_LTO to apply to compiler-rt?
>>> 
>>> It could be just a deficiency of the cmake configuration for LLVM_ENABLE_LTO.
>>> 
>>> You can always not use this flag and instead do something like: -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="-flto"  -DCMAKE_CXX_FLAGS="-flto"
>>> 
>>> Doesn't help - all the compiler-rt sources are being built with -fno-lto. Presumably due to http://llvm.org/viewvc/llvm-project?view=revision&revision=225049
>>> 
>>> Teresa
>>> 
>> 
>> I agree with r225049.  Otherwise, building clang with -flto changes the
>> output of the programs that clang compiles.  A debug build of clang and a
>> release+LTO+PGO build of clang should produce identical executables when
>> compiling the same source.
>> 
>> If we want to enable users to use an LTO'd compiler-rt, it needs to be an
>> opt-in flag on the user side (lumping in with -flto sounds fine?), and it
>> needs to work no matter how clang was built.
> 
> Actually, while it makes sense for the .a, I don't believe the intent of r225049 was to inhibit LTO on a *.so* built by compiler-rt.

Ah, I was thinking about libclang_rt.*.a.  I agree shared objects could
follow clang itself.

> 
> -- 
> Mehdi
> 



More information about the llvm-commits mailing list