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

[Mehdi Amini via llvm-commits]

> 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 <mailto:mehdi.amini at apple.com>> wrote:
> 
>> On May 31, 2016, at 10:00 AM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote:
>> 
>> 
>> 
>> On Tue, May 31, 2016 at 9:47 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> On May 31, 2016, at 9:42 AM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 24, 2016 at 4:01 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto: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 <http://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"

-- 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160531/eaf45fce/attachment.html>