[llvm] r199244 - Reapply "LTO: add API to set strategy for -internalize"

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Apr 2 13:22:46 PDT 2014


> I dispute that.  I think the linker can communicate more clearly with LTO
> *with* the API change, and I don't think it's less obvious which symbols the
> linker wants.
>
>> The the flag in contrast
>> requires a C api addition and an extension to the internalize api.
>
> You're right here; maybe the API change was the wrong direction (especially
> given your profiling results).  I'll CC you directly for LTO patches in the
> future.
>
> But isn't the C API stable?  Isn't it too late to roll back this change?

I think we call it stable between releases. In the past at least I
have made changes knowing that that particular function was not in any
released version.

Even it we are now stuck with it in the C api, I would probably
implement it as close to the C api as possible. For example, please
don't keep the OnlyHidden option in createInternalizePass.

>> Last time there was some concern about the number of calls to preserve
>> symbols I did some benchmarking
>> (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130930/189746.html)
>>
>> ------------------------------
>> I took the
>> largest "shared library" I had at hand: clang with -export_dynamic. On
>> linux gold currently asks for 22922 symbols to be preserved. I applied
>> the attached hack-timeit.patch to test how long it takes for us to get
>> the internalized combined module. On my machine (2010 iMac),  the time
>> is 0.08s, so despite large number of calls and the
>> std::map<std::string>, internalize in general is not too slow. For
>> scale, the verifier takes about 1s. Parsing the bitcode file takes 5s
>> (the file is 118 MB).
>> --------------------------------
>>
>> Have you found a case where the extra calls are actually noticeable?
>
> Probably not.  Since my approach directly modelled what the linker wants, and
> certainly wasn't going to be slower, I never profiled.  (Sorry I missed that
> that conversation; I arrived too late.)
>
> Nick, did you do any profiling of this?

Cheers,
Rafael



More information about the llvm-commits mailing list