[PATCH] D14623: [ThinLTO] Comdat importing fixes and related cleanup

[Teresa Johnson via llvm-commits]

On Mon, Nov 30, 2015 at 1:49 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Right, which is why I have stripDeclsFromComdats() in this patch (see
>> the header comments for that new routine). Forgot about that, so I
>> think the issue with the change made in r254170 interacting badly with
>> comdat groups is not an issue. So the main thing is that what we want
>> here is for the alias to become a decl in the importing module, which
>> happens during global value proto linking at head and as a post-pass
>> after lazy linking in this patch.
>
>
> What I don't get it is why copy it just to drop it in the end. Can't
> we make the right decision when first looking at f2?

Consider the following example:

In the importing module:

define i32 @main() #0 {
entry:
  call void (...) @func1()
  call void (...) @func2()
  ret i32 0
}


In the import source module:

@alias1 = alias void (...), bitcast (void ()* @comdatfunc to void (...)*)
$comdatfunc = comdat any
define linkonce_odr void @comdatfunc() comdat {
entry:
  ret void
}


define void @func1() {
entry:
  ret void
}

define void @func2() {
  call void @alias1()
  ret void
}


Now consider two importing cases:
1) We import func1
2) We import func2

In case 1), we don't need to import the comdat group definitions,
since none are referenced. When we link global value protos and see
the alias, however, we know that we want the source copy of the comdat
(if we are going to link it in), but don't yet know if it is needed.
Eventually we can turn the alias into a declaration, since we didn't
reference and therefore need to materialize and link in any of the
comdat's defs. We could also just delete the alias GV at this point,
but turning it into a declaration also works in the case where we end
up with a reference to a non-comdat alias where the aliasee isn't the
import function, so the approach is more general.

In case 2) we need to import the comdat group due to the reference,
and so comdatfunc's def will be linked into the dest module and the
alias is still an alias to a def and doesn't need to be demoted to a
decl.

A variant on case 2 is if we import a function like func3:

define void @func3() {
   call void @comdat2func
   ret void
}

$comdat2func = comdat any
define linkonce_odr void @comdat2func() comdat {
  call void @alias1
  ret void
}

now when we import func3 we see that it references a comdat where the
selected version of the comdat is from the source, and we therefore
need to import comdat2func and its comdat group. This in turn exposes
the reference to alias1/comdatfunc and we need to import it as well.
So the fact that alias1 will have a defined aliasee is not known until
after we have done all the function body linking.

Note that we may not even have a direct access of the alias during
this particular import, it may just be in the same comdat group as a
referenced comdat that causes the comdat group to be linked in.



>
> Cheers,
> Rafael



-- 
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413