search for: lto_module_get_num_symbol

Hello everyone, ...I should have used a different subject line in the first place... I've asked Rafael a question about GlobalAlias handling in LTOModule::parseSymbols, but he seems to be on vacation... Does anyone knows the answer? Thanks a lot! Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original

...le_t is no longer valid // extern void lto_module_release(lto_module_t mod); // // returns triplet string which the object module was compiled under // extern const char* lto_module_get_target_triplet(lto_module_t mod); // // returns the number of symbols in the object module // extern uint32_t lto_module_get_num_symbols(lto_module_t mod); // // returns the name of the ith symbol in the object module // extern const char* lto_module_get_symbol_name(lto_module_t mod, uint32_t index); // // returns the attributes of the ith symbol in the object module // extern lto_symbol_attributes lto_module_get_symbol_attribu...

...*. Windows people like to play hideous macro tricks with malloc, so I'd provide a corresponding dispose method, keeping the API self-contained. > extern const char* > lto_module_get_target_triplet(lto_module_t mod); LLVM nomenclature is triple, not triplet. > extern uint32_t > lto_module_get_num_symbols(lto_module_t mod); > > extern const char* > lto_module_get_symbol_name(lto_module_t mod, uint32_t index); > > extern lto_symbol_attributes > lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); Why uint32_t instead of size_t? > // > // frees all memory for...

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

On Tue, Nov 12, 2013 at 6:07 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Chandler, > > I don't quite get why you think sharing is not buying us anything... > It reduces the memory footprint of the source modules (there is sharing > among the source modules) and the number of MDNodes created for the > destination module (we do not need to re-create the MDNodes

...ond module > 4) while there are more source modules, goto 1 I'll describe how the darwin linker uses the LTO interface. It may be amenable to earlier module deletion. 1) The darwin linker mmap()s each input file. If it is a bitcode file, it calls lto_module_create_from_memory() then lto_module_get_num_symbols() and lto_module_get_symbol_*() to discover what the module provides and needs. 2) After all object files are loaded (which means no undefined symbols are left), the linker then calls: lto_codegen_create() and then in a for-loop calls lto_codegen_add_module() on each module previously loaded....

...t* length); > > The return value should be non-const. free takes a void*, not a > const void*. Fixed. >> extern const char* >> lto_module_get_target_triplet(lto_module_t mod); > > LLVM nomenclature is triple, not triplet. Fixed. > >> extern uint32_t >> lto_module_get_num_symbols(lto_module_t mod); >> >> extern const char* >> lto_module_get_symbol_name(lto_module_t mod, uint32_t index); >> >> extern lto_symbol_attributes >> lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); > > Why uint32_t instead of size_t? I chan...

...le_t mod); > > > // > // returns triplet string which the object module was compiled under > // > extern const char* > lto_module_get_target_triplet(lto_module_t mod); > > > // > // returns the number of symbols in the object module > // > extern uint32_t > lto_module_get_num_symbols(lto_module_t mod); > > > // > // returns the name of the ith symbol in the object module > // > extern const char* > lto_module_get_symbol_name(lto_module_t mod, uint32_t index); > > > // > // returns the attributes of the ith symbol in the object module > // &g...

On Tue, Nov 12, 2013 at 4:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> >>> On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren