Displaying 4 results from an estimated 4 matches for "lto_codegen_release_memori".
Did you mean:
lto_codegen_release_memory
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
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
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
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