[patch] First step to fix pr11866 during LTO

Nick Kledzik kledzik at apple.com
Thu Oct 3 10:41:09 PDT 2013


One typo in the comment:
+ * Tells LTO optimization passes that a dynamic shared library is being
+ * built and this symbol may be exported. Unless IR semantics allow the symbol
+ * to be made local to the library, it should remain so it can be exported by the
+ * shared library.

Otherwise, LGTM.

-Nick

On Oct 3, 2013, at 8:43 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> When a new API is added to llvm-c/lto.h, please bump LTO_API_VERSION
>> so that the linker can configure itself to use the new function.
> 
> Done.
> 
>> But, is there a better name than “lto_codegen_add_symtab_symbol()”.  That
>> name has no obvious meaning.  All symbols are symbol table symbols…
>> I had to go back and re-read the email thread to figure out what it was
>> supposed to do again.
>> 
>> How about something like (existing plus new):
>> 
>> /**
>> * Tells LTO optimization passes that this symbol must be preserved
>> * because it is referenced by native code or a command line option.
>> */
>> void lto_codegen_add_must_preserve_symbol(lto_code_gen_t cg, const char* symbol);
>> 
>> /**
>> * Tells LTO optimization passes that a dynamic shared library is being
>> * built which exports all global symbols by default.  And that unless C++
>> * semantics allow the symbol to be completely optimized away, it should
>> * remain so it can be exported by the shared library.
>> */
>> void lto_codegen_add_dso_symbol(lto_code_gen_t cg, const char *symbol);
> 
> I like it. I have propagated the s/symtab/dso/ name change and tweaked
> some comments. A new patch is attached.
> 
> Cheers,
> Rafael
> <t.patch>

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


More information about the llvm-commits mailing list