Displaying 9 results from an estimated 9 matches for "lto_module_create_from_memori".
Did you mean:
lto_module_create_from_memory
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