search for: lto_module_is_object_file_in_memori

On Feb 25, 2008, at 5:32 PM, Nick Kledzik wrote: > I've updated the header (enclosed). > > <lto.h> > Hi Nick, My turn. :-) Just one question. Will the comments you have here be doxygen-friendly? (N.B., I'm not an expert on doxygen.) One thing I notice in other code is that the function or variable names are repeated in the comments. There might also be a special

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

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

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

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