llvm dev - Apr 2016 - Lazily Loaded Modules and Linker::LinkOnlyNeeded

>
>
> I understood from his description that he reversed the destination and
> source so that destination is the user code.
> I assumed it was not lazy loaded, but that would explain the question then
> :)
>
> Neil: can you clarify? If Teresa is right, why aren't you materializing
> the destination module entirely?
>
>
I don't think it has ever been tried to use a lazy destination. Having said
that, I don't think isMaterializable should return true for a declaration.

> Even materializing functions from the source module on the fly isn't
> supported right now, is it?
>
>
It is.

Neil, the flag is linked to llvm-link's -only-needed command line option.
At least for simple cases it seems to be working. Given

declare void @g()
define void @f() {
  call void @g()
  ret void
}

and

define void @g() {
  ret void
}
define void @h() {
  ret void
}


linking with "llvm-link -only-needed test1.bc test2.bc" will bring in
g,
but not h. Can you write a testcase showing what you were expecting it to
do but it is not?

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160420/8a762cfa/attachment.html>

On Wed, Apr 20, 2016 at 12:28 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
>> I understood from his description that he reversed the destination and
>> source so that destination is the user code.
>> I assumed it was not lazy loaded, but that would explain the question
>> then :)
>>
>> Neil: can you clarify? If Teresa is right, why aren't you
materializing
>> the destination module entirely?
>>
>>
>
> I don't think it has ever been tried to use a lazy destination. Having
> said that, I don't think isMaterializable should return true for a
> declaration.
>
Looking at isMaterializable, I'm now a little confused about Neil's case
-
the materializable bit is set to true only when the MODULE_CODE_FUNCTION
indicated that it was !isproto, which means it should have a definition in
that module. So I agree with you that isMaterializable shouldn't be
returning true when the symbol is only available as a declaration.

Neil - what case are you trying to handle here? If there is a
materializable definition in the dest module, wouldn't you want to use that
instead of linking one in from the source module?

Teresa

>
>> Even materializing functions from the source module on the fly
isn't
>> supported right now, is it?
>>
>>
> It is.
>
> Neil, the flag is linked to llvm-link's -only-needed command line
option.
> At least for simple cases it seems to be working. Given
>
> declare void @g()
> define void @f() {
>   call void @g()
>   ret void
> }
>
> and
>
> define void @g() {
>   ret void
> }
> define void @h() {
>   ret void
> }
>
>
> linking with "llvm-link -only-needed test1.bc test2.bc" will
bring in g,
> but not h. Can you write a testcase showing what you were expecting it to
> do but it is not?
>
> Cheers,
> Rafael
>
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160420/4c5bc4d2/attachment.html>

Hey all,

For LinkModules, /*dest*/ is a fully materialized module, /*src*/ is a 
lazily loaded module.

 From what I understood, getLinkedToGlobal() is finding the function in 
/*src*/ that matches some function declaration in /*dest*/, and given 
that /*src*/ is lazily loaded it could be un-materialized.

The functions I need brought in from /*src*//**/ into /*dest*/ are 
always declarations in /*dest*/. The problem is that (for some reason) 
the combination of Linker::LinkOnlyNeeded and a function that is not 
materialized will not copy the function body from /*src*/ into /*dest*/.

Cheers,
-Neil.

On 20/04/16 20:39, Teresa Johnson wrote:
>
>
> On Wed, Apr 20, 2016 at 12:28 PM, Rafael Espíndola 
> <rafael.espindola at gmail.com <mailto:rafael.espindola at
gmail.com>> wrote:
>
>
>         I understood from his description that he reversed the
>         destination and source so that destination is the user code.
>         I assumed it was not lazy loaded, but that would explain the
>         question then :)
>
>         Neil: can you clarify? If Teresa is right, why aren't you
>         materializing the destination module entirely?
>
>
>
>     I don't think it has ever been tried to use a lazy destination.
>     Having said that, I don't think isMaterializable should return
>     true for a declaration.
>
>
> Looking at isMaterializable, I'm now a little confused about Neil's
> case - the materializable bit is set to true only when 
> the MODULE_CODE_FUNCTION indicated that it was !isproto, which means 
> it should have a definition in that module. So I agree with you that 
> isMaterializable shouldn't be returning true when the symbol is only 
> available as a declaration.
>
> Neil - what case are you trying to handle here? If there is a 
> materializable definition in the dest module, wouldn't you want to use 
> that instead of linking one in from the source module?
>
> Teresa
>
>
>
>         Even materializing functions from the source module on the fly
>         isn't supported right now, is it?
>
>     It is.
>
>     Neil, the flag is linked to llvm-link's -only-needed command line
>     option. At least for simple cases it seems to be working. Given
>
>     declare void @g()
>     define void @f() {
>       call void @g()
>       ret void
>     }
>
>     and
>
>     define void @g() {
>       ret void
>     }
>     define void @h() {
>       ret void
>     }
>
>
>     linking with "llvm-link -only-needed test1.bc test2.bc" will
bring
>     in g, but not h. Can you write a testcase showing what you were
>     expecting it to do but it is not?
>
>     Cheers,
>     Rafael
>
>
>
>
> -- 
> Teresa Johnson | 	 Software Engineer | 	tejohnson at google.com 
> <mailto:tejohnson at google.com> | 	 408-460-2413
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/d037c799/attachment.html>