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

[Teresa Johnson via llvm-commits]

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?


> --
> Mehdi
>
>
>
>
>
>
>> --
>> Mehdi
>>
>>
>>
>>
>>> > On 2016-May-20, at 08:14, Mehdi AMINI via llvm-commits <
>>> llvm-commits at lists.llvm.org> wrote:
>>> >
>>> > joker.eph added a comment.
>>> >
>>> > I'm don't have a strong opinion, let me ask what Duncan think of that.
>>> >
>>> >
>>> > http://reviews.llvm.org/D20423
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > llvm-commits mailing list
>>> > llvm-commits at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>
>>
>> --
>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>> 408-460-2413
>>
>>
>>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413
>
>
>


-- 
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/869b481d/attachment.html>