search for: llvm_c_lto

I'll work on another round with the feedback so far. On SundayFeb 24, at Feb 24, Sunday11:24 PM, Evan Cheng wrote: > 1. __LTO__ -> LLVM_C_LTO This one is actually interesting. The names started out with llvm in them, but then we realized that this was a generic interface from the linker to some foreign object file format. So, some other compiler could create an LTO shared object that exports the same lto_ interface and it woul...

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 /* ... */...

On Feb 25, 2008, at 11:02 AM, Nick Kledzik wrote: > I'll work on another round with the feedback so far. > > > On SundayFeb 24, at Feb 24, Sunday11:24 PM, Evan Cheng wrote: >> 1. __LTO__ -> LLVM_C_LTO > > This one is actually interesting. The names started out with llvm > in them, but then we realized that this was a generic interface from > the linker to some foreign object file format. So, some other > compiler could create an LTO shared object that exports the same &g...

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

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 point. > 2. Do we need tho...

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