Clemens Hammacher
2012-Feb-02 12:30 UTC
[LLVMdev] Disjoint types after reading several modules
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 the types to unify. This leads to interesting effects in some cases, but I'll write another post about this. Nevertheless the TypeMapTy is a great piece of code, and we will definitely reuse it to remap duplicated types (and composed types) to unique ones (via mutateType(), recursively descending to all uses).> I have to ask: why are you writing these modules out as separate bc files?I knew that someone would ask that ;) We need to have separate modules during runtime. One of them contains the code that is actually JIT compiled and executed, and simultaneously different optimizations are concurrently (in individual threads) building up or restructuring new code in their individual "working modules". Eventually some code will get copied over to the main module to be executed, and that's why they need to use the same types. Cheers, Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6392 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120202/7d96d23a/attachment.bin>
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. > > I already looked into that. The linker is using the GlobalValues of both modules > to identify the types to unify. > This leads to interesting effects in some cases, but I'll write another post > about this. > > Nevertheless the TypeMapTy is a great piece of code, and we will definitely > reuse it to remap duplicated types (and composed types) to unique ones (via > mutateType(), recursively descending to all uses). > >> I have to ask: why are you writing these modules out as separate bc files? > > I knew that someone would ask that ;) > We need to have separate modules during runtime. One of them contains the code > that is actually JIT compiled and executed, and simultaneously different > optimizations are concurrently (in individual threads) building up or > restructuring new code in their individual "working modules". Eventually some > code will get copied over to the main module to be executed, and that's why they > need to use the same types.what do you mean by "copied over to the main module"? If you want to add additional IR to the main module then you should link it in using the linker. Ciao, Duncan.
Clemens Hammacher
2012-Feb-02 13:25 UTC
[LLVMdev] Disjoint types after reading several modules
On 2/2/12 1:51 PM, Duncan Sands wrote:> On 02/02/12 13:30, Clemens Hammacher wrote: >> On 2/2/12 1:15 AM, Chris Lattner wrote: >>> I have to ask: why are you writing these modules out as separate bc files? >> >> I knew that someone would ask that ;) >> We need to have separate modules during runtime. One of them contains the code >> that is actually JIT compiled and executed, and simultaneously different >> optimizations are concurrently (in individual threads) building up or >> restructuring new code in their individual "working modules". Eventually some >> code will get copied over to the main module to be executed, and that's why they >> need to use the same types. > > what do you mean by "copied over to the main module"? If you want to add > additional IR to the main module then you should link it in using the linker.I think that the linker would indeed be able to remap the types correctly, but the main obstacle here is that we only copy individual functions. Maybe it would be possible to first copy the function into a new module, and then link this into the main module, but then again the question is how to correctly copy the function to the temporary module ;) Another thing is that for the transformations, it would be much nicer if the types in all working modules are the same as in the main module. This copying of individual functions between modules works very well *if* the used types are the same. All that had to be changed is the remapping, because we have to remap the global values as well. We are basically using a slightly extended version of the MapValue function. So let's concentrate on how to get the types unique ;) Cheers, Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6392 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120202/db1d3cc7/attachment.bin>
Reasonably Related Threads
- [LLVMdev] Disjoint types after reading several modules
- [LLVMdev] Disjoint types after reading several modules
- [LLVMdev] Disjoint types after reading several modules
- [LLVMdev] Disjoint types after reading several modules
- [LLVMdev] Disjoint types after reading several modules