search for: lto_codegen_set_pic_model

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We

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

...info should be generated // returns true on error (check lto_get_error_message() for details) // extern bool lto_codegen_set_debug_model(lto_code_gen_t cg, lto_debug_model); // // sets what code model to generated // returns true on error (check lto_get_error_message() for details) // extern bool lto_codegen_set_pic_model(lto_code_gen_t cg, lto_codegen_model); // // adds to a list of all global symbols that must exist in the final // generated code. If a function is not listed there, it might be // inlined into every usage and optimized away. // extern void lto_codegen_add_must_preserve_symbol(lto_code_gen_t cg,...

...eck lto_get_error_message() for details) > // > extern bool > lto_codegen_set_debug_model(lto_code_gen_t cg, lto_debug_model); > > > // > // sets what code model to generated > // returns true on error (check lto_get_error_message() for details) > // > extern bool > lto_codegen_set_pic_model(lto_code_gen_t cg, lto_codegen_model); > > > // > // adds to a list of all global symbols that must exist in the final > // generated code. If a function is not listed there, it might be > // inlined into every usage and optimized away. > // > extern void > lto_codegen_a...