search for: lto_codegen_add_modul

...o_module_create_from_memory() then lto_module_get_num_symbols() and lto_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 w...

> 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 would be to > immediately call lto_codegen_add_module() right after > lto_module_create_from_memory(), then lto_module_dispose(). That is, never > have any unmerged modules...

LTOCodeGenerator::addModule (which is wrapped by lto_codegen_add_module) takes an LTOModule as an argument and links the latter's llvm::Module into its own. It does not change the latter's llvm::Module. The lto_module_dispose API call destroys an LTOModule. This frees the LTOModule's llvm::Module, but also invalidates strings returned by, e.g., lto_modul...

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

On Wed, Nov 13, 2013 at 7:58 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > 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 would be to > > immediately call lto_codegen_add_module() right after > > lto_module_create_from_memory(), then lto_module_dispose(). That is, > never >...

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

...ile descriptors. With only 2 objects loaded at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? That is odd. I will debug it in a sec, but we have in the claim_file_hook: if (code_gen) { if (lto_codegen_add_module(code_gen, M)) { (*message)(LDPL_ERROR, "Error linking module: %s", lto_get_error_message()); return LDPS_ERR; } } lto_module_dispose(M); In fact, with current gold we call get_view, so the plugin uses the same fd as gold. It might actually be a bug...

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

...nly 2 objects loaded at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? > > That is odd. I will debug it in a sec, but we have in the claim_file_hook: > > if (code_gen) { > if (lto_codegen_add_module(code_gen, M)) { > (*message)(LDPL_ERROR, "Error linking module: %s", > lto_get_error_message()); > return LDPS_ERR; > } > } > > lto_module_dispose(M); > > In fact, with current gold we call get_view, so the plugin uses the >...

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

...ed at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? >> >> That is odd. I will debug it in a sec, but we have in the claim_file_hook: >> >> if (code_gen) { >> if (lto_codegen_add_module(code_gen, M)) { >> (*message)(LDPL_ERROR, "Error linking module: %s", >> lto_get_error_message()); >> return LDPS_ERR; >> } >> } >> >> lto_module_dispose(M); >> >> In fact, with current gold we call get_...

...ry for a code generator // upon return the lto_code_gen_t is no longer valid // extern void lto_codegen_release(lto_code_gen_t); // // add an object module to the set of modules for which code will be generated // returns true on error (check lto_get_error_message() for details) // extern bool lto_codegen_add_module(lto_code_gen_t cg, lto_module_t mod); // // sets what if any format of debug info should be generated // returns true on error (check lto_get_error_message() for details) // extern bool lto_codegen_set_debug_model(lto_code_gen_t cg, lto_debug_model); // // sets what code model to generated //...

...o longer valid > // > extern void > lto_codegen_release(lto_code_gen_t); > > > > // > // add an object module to the set of modules for which code will be > generated > // returns true on error (check lto_get_error_message() for details) > // > extern bool > lto_codegen_add_module(lto_code_gen_t cg, lto_module_t mod); > > > > // > // sets what if any format of debug info should be generated > // returns true on error (check lto_get_error_message() for details) > // > extern bool > lto_codegen_set_debug_model(lto_code_gen_t cg, lto_debug_model); &g...