search for: typemapti

Hi Chris, thanks for your answer! On 2/2/12 1:15 AM, Chris Lattner wrote: > The linker has to solve the exact same problem (read multiple .bc files and unify types across them). This is the impetus behind TypeMapTy in lib/Linker/LinkModules.cpp. You'll probably need to do something like that. I already looked into that. The linker is using the GlobalValues of both modules to identify

On Jan 31, 2012, at 6:16 AM, Clemens Hammacher wrote: > This is because each module contains its own type table with all the types used in that module. When reading in the corresponding bitcode, the BitcodeReader explicitly calls StructType::create, without looking up in the context whether an equivalent type (even with the same name) already exists. > So I think that llvm is behaving

Dear community, we are currently facing a problem related to the new type system in llvm 3.0. Our setting is the following: We have two or more modules, all in the same LLVMContext. They are sharing some types, meaning that for example functions in different modules are referencing the same (meaning pointer identical) type. Now we write the different modules to the disk, and read them back

Hi Clemens, On 02/02/12 13:30, Clemens Hammacher wrote: > Hi Chris, > thanks for your answer! > > On 2/2/12 1:15 AM, Chris Lattner wrote: >> The linker has to solve the exact same problem (read multiple .bc files and >> unify types across them). This is the impetus behind TypeMapTy in >> lib/Linker/LinkModules.cpp. You'll probably need to do something like that.