search for: sunday11

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

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 > compile...

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

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