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

[Teresa Johnson via llvm-commits]

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



> --
> Mehdi
>
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160531/939acb25/attachment.html>