llvm dev - Feb 2012 - [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>

Hi Clemens,

On 02/02/12 14:25, Clemens Hammacher wrote:
> On 2/2/12 1:51 PM, Duncan Sands wrote:
...
>> 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 ;)
llvm-extract?

Ciao, Duncan.

On 2/2/12 2:32 PM, Duncan Sands wrote:
> On 02/02/12 14:25, Clemens Hammacher wrote:
>> On 2/2/12 1:51 PM, Duncan Sands wrote:
> ...
>>> 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 ;)
>
> llvm-extract?
Ah, thanks, I didn't know that tool.
But I don't think it's applicable here. It's a command-line tool
which
removes all global values and functions which were not explicitely 
stated on the command line, and then dumps the remaining module.

Are you proposing to
- compute the set of referenced global values and functions from the 
individual function
- write the working module to the disk
- run llvm-extract
- read the extracted module
- use the linker to link it into the main module?

Then I think it's easier to use our current implementation, and just fix 
the issue with the duplicated types.

Sorry if I misunderstood your suggestion.

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/02e2c185/attachment.bin>