search for: parsetypetablebody

Several people on this list have reported issues 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), hav...

...gt; Several people on this list have reported issues 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). The BitcodeReader has nothing to do with the issue in question; the relevant code is in lib/Linker. -Eli

...eople on this list have reported issues 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...

...t; Several people on this list have reported issues 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 >...

...r why the system, because > of the lack of type linkage, is lenient in "unioning" types. What I'm still uncomfortable with is, I > don't understand under what conditions the system should union two opaque types with the > same name and def. The above method BitcodeReader::ParseTypeTableBody, never seems to do > this, and therefore my reading of Linker::LinkInFiles won't do it either for say two bitcode files > accessing/realizing the same named StructType. The idea is that the linker does this when there is linkage that implies that two types should be unioned. For exampl...

...on the assert later. The second approach is to *not* cache modules but re-read them from disk (or memory, but that's irrelevant here). That works without any sort of asserts, but "leaks" memory because everytime a module is re-read from disk it re-creates types (cf BitcodeReader.cpp:parseTypeTableBody()). Creating a different LLVMContext for every single expression used seems infeasible, and fixing LLVM to have type lifetimes bound to Modules seems daunting. Therefore the first approach seems preferable by far. What I'm observing is that creating the same Module contents (modulo some const...

...; > The second approach is to *not* cache modules but re-read them from disk > (or memory, but that's irrelevant here). That works without any sort of > asserts, but "leaks" memory because everytime a module is re-read from > disk it re-creates types (cf BitcodeReader.cpp:parseTypeTableBody()). > Creating a different LLVMContext for every single expression used seems > infeasible, and fixing LLVM to have type lifetimes bound to Modules > seems daunting. The idea would be to fix LLVM to have LLVMContext lifetime bound to llvm::Module (perhaps, reference-counted), but yes, it&...

...ond approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf BitcodeReader.cpp:parseTypeTableBody()). > > Creating a different LLVMContext for every single expression used seems > > infeasible, and fixing LLVM to have type lifetimes bound to Modules > > seems daunting. > > The idea would be to fix LLVM to have LLVMContext lifetime bound to > llvm::Module (perhaps, re...

...ach is to *not* cache modules but re-read them from disk >>> (or memory, but that's irrelevant here). That works without any sort of >>> asserts, but "leaks" memory because everytime a module is re-read from >>> disk it re-creates types (cf BitcodeReader.cpp:parseTypeTableBody()). >>> Creating a different LLVMContext for every single expression used seems >>> infeasible, and fixing LLVM to have type lifetimes bound to Modules >>> seems daunting. >> >> The idea would be to fix LLVM to have LLVMContext lifetime bound to >> llvm...