search for: lto_codegen_compile

Yes,but when I just simply replace lto_codegen_compile(cg, ...) with lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the gold-plugin.cpp to see if it will generate a correct bc file,the llvm-gcc/llvm-g++ will call the native ld in the linking step,which causes the failture because of that ld can not recognize an object file whic...

On Aug 31, 2010, at 10:43 AM, Rafael Espindola wrote: >> I am not sure why "before it is optimized?". May be this is gold specific ? >> >> One of the use of this utility is a debugging aid. The linker can select to do this when -save-temps is used on the command line. > > I think an example will explain. Lets say we have a function foo that > is unused. The

2009/10/19 zhunan <zhunansjtu at gmail.com>: > Yes,but when I just simply replace lto_codegen_compile(cg, ...) with > lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the > gold-plugin.cpp to see if it will generate a correct bc file,the > llvm-gcc/llvm-g++ will call the native ld in the linking step,which > causes the failture because of that ld can not recognize...

...at the last final link > steps gold will still generate native code. However, it should be > possible to find a way to get gold to leave the merged bitcode around > somewhere, or perhaps do something like llvm-ld. Nicholas? It's easy. In gold-plugin.cpp all_symbols_read_hook() where lto_codegen_compile(cg, ...) is currently called, call lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. If someone were to rig this up to a command-line flag (search for LDPT_OPTION in the same file) then I would like to commit that change. Nick > The advantage of this approach is...

...> steps gold will still generate native code. However, it should be > > possible to find a way to get gold to leave the merged bitcode around > > somewhere, or perhaps do something like llvm-ld. Nicholas? > > It's easy. In gold-plugin.cpp all_symbols_read_hook() where > lto_codegen_compile(cg, ...) is currently called, call > lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. > > If someone were to rig this up to a command-line flag (search for > LDPT_OPTION in the same file) then I would like to commit that change. > > Nick > > >...

.../ generates code for all added modules into one object file // On sucess returns a pointer to a generated mach-o buffer and // length set to the buffer size. Client must free() the buffer // when done. // On failure, returns NULL (check lto_get_error_message() for details) // extern const uint8_t* lto_codegen_compile(lto_code_gen_t cg, size_t* length); #ifdef __cplusplus } #endif #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080222/81b5d50e/attachment.html>

...o one object file > // On sucess returns a pointer to a generated mach-o buffer and > // length set to the buffer size. Client must free() the buffer > // when done. > // On failure, returns NULL (check lto_get_error_message() for > details) > // > extern const uint8_t* > lto_codegen_compile(lto_code_gen_t cg, size_t* length); The return value should be non-const. free takes a void*, not a const void*. Windows people like to play hideous macro tricks with malloc, so I'd provide a corresponding dispose method, keeping the API self-contained. > extern const char* > lto_m...

...at the last final link > steps gold will still generate native code. However, it should be > possible to find a way to get gold to leave the merged bitcode around > somewhere, or perhaps do something like llvm-ld. Nicholas? It's easy. In gold-plugin.cpp all_symbols_read_hook() where lto_codegen_compile(cg, ...) is currently called, call lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. If someone were to rig this up to a command-line flag (search for LDPT_OPTION in the same file) then I would like to commit that change. Nick > The advantage of this approach is...

...e at the last final link > steps gold will still generate native code. However, it should be > possible to find a way to get gold to leave the merged bitcode around > somewhere, or perhaps do something like llvm-ld. Nicholas? It's easy. In gold-plugin.cpp all_symbols_read_hook() where lto_codegen_compile(cg, ...) is currently called, call lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. If someone were to rig this up to a command-line flag (search for LDPT_OPTION in the same file) then I would like to commit that change. Nick > The advantage of this approach is th...

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

2009/10/17 zhunan <zhunansjtu at gmail.com>: > Thank you for the reply,but I meant that when we building,we can not use > the native tools such ar and as to process the llvm files,we must have > the ability to call llvm-ar and llvm-as instead of the native ones. We can use the native tools if they understand llvm IL :-) That is what the plugin does. With it installed you can run

Thank you for the reply,but I meant that when we building,we can not use the native tools such ar and as to process the llvm files,we must have the ability to call llvm-ar and llvm-as instead of the native ones. 在 2009-10-17六的 19:35 -0700，Nick Lewycky写道： > zhunan wrote: > > Hi, > > > > I don't think just use gold-plugin even modified is enough for the task > > of

On Tue, Nov 12, 2013 at 6:07 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Chandler, > > I don't quite get why you think sharing is not buying us anything... > It reduces the memory footprint of the source modules (there is sharing > among the source modules) and the number of MDNodes created for the > destination module (we do not need to re-create the MDNodes

...to_module_get_symbol_*() to discover what the module provides and needs. 2) After all object files are loaded (which means no undefined symbols are left), the linker then calls: lto_codegen_create() and then in a for-loop calls lto_codegen_add_module() on each module previously loaded. 3) After lto_codegen_compile() has returned, the linker does clean up and deletes each module with lto_module_dispose(). It sounds like the linker could call lto_module_dispose() right after lto_codegen_add_module() to help reduce the memory footprint. That would be a simple linker change. A slightly larger linker change wo...

On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors <timo.lindfors at iki.fi> wrote: > Tianwei <tianwei.sheng at gmail.com> writes: >> someone suggested me to use gold-plugin, I know nothing about it yet, I will >> have a try later.  Does anyone have a good solution for this problem? > > Afaik gold does not help here. I tried it and managed to only generate >

...sucess returns a pointer to a generated mach-o buffer and >> // length set to the buffer size. Client must free() the buffer >> // when done. >> // On failure, returns NULL (check lto_get_error_message() for >> details) >> // >> extern const uint8_t* >> lto_codegen_compile(lto_code_gen_t cg, size_t* length); > > The return value should be non-const. free takes a void*, not a > const void*. Fixed. >> extern const char* >> lto_module_get_target_triplet(lto_module_t mod); > > LLVM nomenclature is triple, not triplet. Fixed. > >>...

Tianwei <tianwei.sheng at gmail.com> writes: > someone suggested me to use gold-plugin, I know nothing about it yet, I will > have a try later. Does anyone have a good solution for this problem? Afaik gold does not help here. I tried it and managed to only generate native code. I'm currently investigating an alternative approach to produce whole-program bitcodes: 1) add

...o one object file > // On sucess returns a pointer to a generated mach-o buffer and > // length set to the buffer size. Client must free() the buffer > // when done. > // On failure, returns NULL (check lto_get_error_message() for > details) > // > extern const uint8_t* > lto_codegen_compile(lto_code_gen_t cg, size_t* length); > > > #ifdef __cplusplus > } > #endif > > > #endif > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailma...

On Tue, Nov 12, 2013 at 4:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> >>> On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren