search for: namedstructtypes

...ues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do I see this use anywhere else in BitcodeReader's implementation (.cpp file). Doesn't the context's NamedStructTypes (checking for a previously created StructType with the same name), have to be used before setName(…) is called so that a new struct...

...regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), > I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). > Nor do I see this use anywhere else in BitcodeReader's implementation (.cpp file). > > Doesn't the context's NamedStructTypes (checking for a previously created StructType > with the same name), have to be used before setName(…) is called...

...regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), > I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). > Nor do I see this use anywhere else in BitcodeReader's implementation (.cpp file). The BitcodeReader has nothing to do with the issue in question; the relevant code is in lib/Linker. -Eli

...;> named StructType instance with the same name in two different modules >> being resolved into two StructTypes with different names due to StructType:: >> setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), >> I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). >> Nor do I see this use anywhere else in BitcodeReader's implementation (.cpp file). >> >> Doesn't the context's NamedStructTypes (checking for a previously created StructType >> with the same name), have to be used before setNa...

...mp;ErrMsg)); module->dump(); } } with smart pointer, the 1st module will be deleted and call removeModule for the context. The implementation of removeModule is quite simple. It just removes the PtrSet. pImpl->OwnedModules.erase(M); It doesn't touch LLVMContextImpl's NamedStructTypes. As a result, 'struct.cmd' is still in the symbol table even the module has destroyed. In second ParseBitCodeFile, StructType::setName will introduce struct.cmd0 due to conflict. should we do thorough cleanup for the method removeModule? or why does llvm retain NamedStructTypes? thanks,...

...@G = external global %A* ...and... %A = type { i32 } @G = global %A* null should merge the two %a's, because that is implied by linking @G and there is no structural conflict. > On the other hand when hand coding two > modules using in memory IR, I have a choice in either checking with NamedStructTypes to to force > two equivalently named struct types to resolve to the same struct type with the same name, or > ignoring the issue, and just have each module create two different struct types (via StructType > name collision behavior), with different names but with the same definition. Does...

...pStr(Name); > TempStr.push_back('.'); > raw_svector_ostream TmpStream(TempStr); > unsigned NameSize = Name.size(); > > do { > TempStr.resize(NameSize + 1); > TmpStream.resync(); > TmpStream << getContext().pImpl->NamedStructTypesUniqueID++; > > Entry = &getContext().pImpl-> > NamedStructTypes.GetOrCreateValue(TmpStream.str()); > } while (Entry->getValue()); > } > > > — > Mehdi > >> On Jun 2, 2015, at 11:23 AM, Haopeng Liu <hyliuhp at g...

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly accessed by my code(a subclass of ModulePass). So how can I iterate all the Types in a Module? Thanks. Regards, Thomas Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

Hi All, I generated the following code with "clang -flto" command. void test(struct StruTyName *a) { ... } Then the type of test function is "void (%struct.StruTyName.100*)" by calling function::getFunctionType API. What's the meaning of number 100? Best, Haopeng

...39;.'); >>> raw_svector_ostream TmpStream(TempStr); >>> unsigned NameSize = Name.size(); >>> do { >>> TempStr.resize(NameSize + 1); >>> TmpStream.resync(); >>> TmpStream << getContext().pImpl->NamedStructTypesUniqueID++; >>> Entry = &getContext().pImpl-> >>> NamedStructTypes.GetOrCreateValue(TmpStream.str()); >>> } while (Entry->getValue()); >>> } >>> >>> >>> — >>> Mehdi >>>...

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly accessed by my code(a subclass of ModulePass). So how can I iterate all the Types in a Module? Thanks. Regards, Thomas Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

...e, for instance, I think that the ordering of instantiation I'm making use of may change. 2. I'm unable to retrieve all defined named types from the module. I know there is LLVMContextImpl but this class is a forward declaration and therefore I'm not able to access LLVMContextImpl::NamedStructTypes. Thanks for any suggestions. Best regards, Sebastian -- Mit freundlichen Grüßen / Kind regards Sebastian Dreßler Zuse Institute Berlin (ZIB) Takustraße 7 D-14195 Berlin-Dahlem Germany dressler at zib.de Phone: +49 30 84185-261 http://www.zib.de/