search for: lto_codegen_dispose

...to get gold to leave the merged bitcode around >somewhere, or perhaps do something like llvm-ld. Nicholas? > I've had some success by adding a call to lto_codegen_write_merged_modules(cg, somePath) at the end of the gold plugin's all_symbols_read_hook() function just before it calls lto_codegen_dispose(cg). The somePath is set via a plugin option which I patched llvm-gcc to pass through as a derivation from its -o argument. It has worked on several mid-complexity applications I've tried so far (lighttpd, wu-ftpd, tcdump, and the sqlite library). I would be interested in seeing more of Timo...

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

...interface is llvm independent. It may even migrate out of include/llvm-c at some point. > 2. Do we need those #include's? We need stddef.h for size_t and stdbool.h for bool. > 4. lto_codegen_release -> lto_codegen_release_memory to be clearer > and more consistent. Renamed to lto_codegen_dispose() > 5. Use C comments /* ... */? Fixed. > 6. Please start comments with capital letters and end sentences > with periods! Or perhaps not since it'll drive Chris nuts. :-) Fixed. On Feb 24, 2008, at 6:10 PM, Gordon Henriksen wrote: >> #include <stdint.h> >> #inc...

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

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