[llvm] [ThinLTO] Do not duplicate import a function that is actually defined in the current module (PR #110064)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> It also possibly reveals another bug (not related, won't cause immediate trouble). If there is a template with function pointer parameter, and there's an instantiation of the template but the function used is not defined, then the optimizer could do away the metadata info for the template parameter, so we will ended up non-identical metadata type nodes with the same name in different modules.
> 
> ```
> template <void (*Func)()>
> struct S {
>   void Impl() {
>     Func();
>   }
> };
> 
> void func1();
> 
> void bar() {
>   S<func1> s ; 
> }
> ```
> 
> ```
> !18 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S<&func1>", file: !11, line: 2, size: 8, flags: DIFlagTypePassByValue, elements: !19, templateParams: !20, identifier: "_ZTS1SIXadL_Z5func1vEEE")
> !19 = !{}
> !20 = !{!21}
> !21 = !DITemplateValueParameter(name: "Func", type: !22, value: ptr @_Z5func1v)
> ```
> 
> If `func1` is not defined in the current module, then the value in `!21` could be optimized away and becomes `undef`, not sure if this is the correct behavior

The non-LTO behavior if `func1` was undefined would be to fail to link. One could make an argument that ThinLTO should match, wherever possible, the non-LTO behavior.

Alternatively, GCC never produces references to these pointer non-type-template parameters anyway, because doing so can lead to different behavior when building with and without debug info (failure to link is the least problematic one - more problematic would be if the linker pulled in new object files to satisfy the reference, then had global ctors in them that ran - changing program behavior).

I will say, ideally, if the function is optimized away, rather than using 0 for the value in the DWARF, we should, ideally, use the "tombstone" value (which should be -1/maxint/etc, ideally) though that does require a bit of a special case in the linker. That'll make it clear that this value is different from a null pointer which is a valid value for a non-type template parameter of pointer type.

But don't feel like you have to solve that problem - this is pretty niche and, again, GCC provides no value due to these complications, so we're not missing out on some important opportunity.

https://github.com/llvm/llvm-project/pull/110064