search for: lto_module_create_from_memori

Displaying 9 results from an estimated 9 matches for "lto_module_create_from_memori".

2013 Nov 13
2
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
On Nov 12, 2013, at 6:11 PM, Chandler Carruth <chandlerc at google.com> wrote: > 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
2013 Nov 14
0
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
> 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
2013 Nov 13
0
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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
2008 Feb 23
5
[LLVMdev] new LTO C interface
Hello. I work at Apple on our linker. We are working to improve support for llvm in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h> a C++ interface which allows the linker to process llvm bitcode files along with native mach-o object files. For the next step we'd like our other tools like nm, ar, and lipo to be able to transparently process bitcode files
2008 Feb 25
0
[LLVMdev] new LTO C interface
Hi Nick, I don't have any comments on the substance of the APIs (I'm not expert in this area), just some style notes. Overall, the capitalization style is inconsistent with the bulk of the C bindings, which are more Carbon than GNU. On Feb 23, 2008, at 01:34, Nick Kledzik wrote: > #include <stdint.h> > #include <stdbool.h> Note that MSVC++ still doesn't
2013 Nov 13
2
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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
2008 Feb 26
2
[LLVMdev] new LTO C interface
I've updated the header (enclosed).  On Feb 24, 2008, at 11:24 PM, Evan Cheng wrote: > 1. __LTO__ -> LLVM_C_LTO > 3. Rather than using underscore in function names, e.g. lt_foo_bar, > use capital letters and also start with prefix LLVM. e.g. > LLVMLTOFooBar. As we discussed, this is interface is llvm independent. It may even migrate out of include/llvm-c at some
2013 Nov 14
4
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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()
2008 Feb 25
0
[LLVMdev] new LTO C interface
More stylistic nitpicking for consistency sakes... 1. __LTO__ -> LLVM_C_LTO 2. Do we need those #include's? 3. Rather than using underscore in function names, e.g. lt_foo_bar, use capital letters and also start with prefix LLVM. e.g. LLVMLTOFooBar. 4. lto_codegen_release -> lto_codegen_release_memory to be clearer and more consistent. 5. Use C comments /* ... */? 6. Please start