search for: lto_codegen_write_merged_modul

...tions are, so that I could also apply them while compiling >> per file bytecode to native code. >> >> Or am I using the wrong way to compile per file bytecode to native code? > > Gold uses the libLTO interface. I think there is a small bug (strange > design?) in libLTO: lto_codegen_write_merged_modules will write the > bitcode files after they are merged and internalized, but before other > optimizations are run. We should probably change that or add a new > function to libLTO that gives us access to the optimized code. > > Can someone more familiar with libLTO comment why write...

...t;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 output of lto_codegen_write_merged_modules will have foo in it, but it will be marked as an internal function. The .o produced by libLTO will not have foo anymore. > - > Devang Cheers, -- Rafael Ávila de Espíndola

...?". 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 output of lto_codegen_write_merged_modules will have > foo in it, but it will be marked as an internal function. The .o > produced by libLTO will not have foo anymore. Would not it be useful to debug LLVM optimizer bugs ? BTW, if you call lto_codegen_write_merged_modules() from linker after optimization but before generating machi...

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 which contains LLVM's IL. I understand the f...

Hi, I found some posts on the topic of whole program bitcode and gold plugin. I put lto_codegen_write_merged_modules(cg, "/path/to/output.bc") into gold-plugin.cpp all_symbols_read_hook() and compiled one autotooled program (ftp://ftp.gnu.org/gnu/diction/diction-1.11.tar.gz) as described in the gold plugin document, however, I still did not see the output.bc. Can anyone has succeeded in doing this...

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 an object file > which contains LLVM's IL....

...d enough, because 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? > I've had some success by adding a call to lto_codegen_write_merged_modules(cg, somePath) at the end of the gold plugin's all_symbols_read_hook() function just before it calls lto_codegen_dispose(cg). The somePath is set via a plugin option which I patched llvm-gcc to pass through as a derivation from its -o argument. It has worked on several mid-complexity applica...

...me what > those optimizations are, so that I could also apply them while compiling > per file bytecode to native code. > > Or am I using the wrong way to compile per file bytecode to native code? Gold uses the libLTO interface. I think there is a small bug (strange design?) in libLTO: lto_codegen_write_merged_modules will write the bitcode files after they are merged and internalized, but before other optimizations are run. We should probably change that or add a new function to libLTO that gives us access to the optimized code. Can someone more familiar with libLTO comment why write_merged_modules writes th...

Hi, I am using gold plugin with the option "-use-gold-plugin -Wl,-plugin-opt=also-emit-llvm" to compile apache. I objdumped the final executable httpd to httpd.S. I also compiled those per file bytecode into native code using the following: llc filename.o llvm-gcc -c filename.o.s -o filename.o.o Then I objdumped filename.o.o to filename.o.S and compared some functions between

...ate 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 that it will potentially work with > build systems that call ar/...

...t 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 that it will potentially work with &...

...ate 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 that it will potentially work with > build systems that call ar/...

...erate 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 that it will potentially work with > build systems that call ar/l...

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

...d away. // extern void lto_codegen_add_must_preserve_symbol(lto_code_gen_t cg, const char* symbol); // // writes a new file at the specified path that contains the // merged contents of all modules added so far. // returns true on error (check lto_get_error_message() for details) // extern bool lto_codegen_write_merged_modules(lto_code_gen_t cg, const char* path); // // 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_m...

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 >

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

...erve_symbol(lto_code_gen_t cg, const char* > symbol); > > > // > // writes a new file at the specified path that contains the > // merged contents of all modules added so far. > // returns true on error (check lto_get_error_message() for details) > // > extern bool > lto_codegen_write_merged_modules(lto_code_gen_t cg, const char* path); > > > // > // 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 failur...