LTO is working just fine with Firefox right now, except that I cannot enable debug information. With debug, linking a single .o into a .so with valgrind shows: ==24373== 36,311,472 bytes in 71,717 blocks are possibly lost in loss record 1,192 of 1,192 ==24373== at 0x4C2815C: malloc (vg_replace_malloc.c:236) ==24373== by 0x6CD42C4: llvm::MDNode::getMDNode(llvm::LLVMContext&, llvm::Value* const*, unsigned int, llvm::MDNode::FunctionLocalness, bool) (Metadata.cpp:226) The file itself is 4.5MB, so 36MB from just this allocation spot is a lot. Having 71,717 blocks also suggests that we should be using some pool. For now I would be more then happy if I was just able to free that. lto_module_dispose is being called and the llvm module is being destructed, but it looks like the only way to free the metadata is to destroy the LLVMContext. Is this by design? why? Thanks, Rafael
2011/2/20 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>:> LTO is working just fine with Firefox right now, except that I cannot > enable debug information. > > With debug, linking a single .o into a .so with valgrind shows: > > ==24373== 36,311,472 bytes in 71,717 blocks are possibly lost in loss > record 1,192 of 1,192 > ==24373== at 0x4C2815C: malloc (vg_replace_malloc.c:236) > ==24373== by 0x6CD42C4: llvm::MDNode::getMDNode(llvm::LLVMContext&, > llvm::Value* const*, unsigned int, llvm::MDNode::FunctionLocalness, > bool) (Metadata.cpp:226) > > The file itself is 4.5MB, so 36MB from just this allocation spot is a > lot. Having 71,717 blocks also suggests that we should be using some pool. > > For now I would be more then happy if I was just able to free that. > lto_module_dispose is being called and the llvm module is being > destructed, but it looks like the only way to free the metadata is to > destroy the LLVMContext. Is this by design? why?Types, constants, and metadata are all associated with the LLVMContext; the primary reason for this is that it maintains pointer equality across modules, which is nice for cross-module work like linking. It's worth noting there isn't any strong reason to reuse an LLVMContext for multiple modules if you're not using the module linker or something like it. The LLVMContext design was introduced primarily to allow multi-threading, but it can also be used for memory management. -Eli
> Types, constants, and metadata are all associated with the > LLVMContext; the primary reason for this is that it maintains pointer > equality across modules, which is nice for cross-module work like > linking. > > It's worth noting there isn't any strong reason to reuse an > LLVMContext for multiple modules if you're not using the module linker > or something like it. The LLVMContext design was introduced primarily > to allow multi-threading, but it can also be used for memory > management.I could try that, but using the plugin in nm and ar is a degenerate case. Once that works the build will get to the linker... Shouldn't we at least free the metadata when no module is using it? The metadata in a debug build is a lot larger than the IL itself...> -EliCheers, Rafael