<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 12:36 PM Alexey Lapshin <<a href="mailto:alapshin@accesssoftek.com" target="_blank">alapshin@accesssoftek.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow...<br>
</p>
<p><br>
</p>
<p>>Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)?</p>
<p>> - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc.<br>
</p>
<div style="color:rgb(33,33,33)">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>There are two general requirements: <br>
1) Remove (or clean) invalid debug info. <br></div></div></div></div></div></div></blockquote><div><br>Perhaps a simpler direct solution for your immediate needs might be a much narrower, and more efficient linker-DWARF-awareness feature:<br><br>With DWARFv5, rnglists present an opportunity for a DWARF linker to rewrite the ranges without parsing the rest of the DWARF. /technically/ this isn't guaranteed - rnglist entries can be referenced either directly, or by index. If all rnglists are referenced by index, then a linker could parse only the debug_rnglists section and rewrite ranges to remove any address ranges that refer to optimized-out code.<br><br>This would only be correct for rnglists that had no direct references to them (that only were referenced via the indexes) - but we could either implement it with that assumption, or could add an LLVM extension attribute on the CU that would say "I promise I only referenced rnglists via rnglistx forms/indexes). If this DWARF-aware linking would have to read the CU DIE (not all the other DIEs) it /could/ also then rewrite high/low_pc if the CU wasn't using ranges... but that wouldn't come up in the function-removal case, because then you'd have ranges anyway, so no need for that.<br><br>Such a DWARF-aware rnglist linking could also simplify rnglists, in cases where functions ended up being laid out next to each other, the linker could coalesce their ranges together.<br><br>I imagine this could be implemented with very little overhead to linking, especially compared to the overhead of full DWARF-aware linking.<br><br>Though none of this fixes Split DWARF, where the linker doesn't get a chance to see the addresses being used - but if you only want/need the CU-level ranges to be correct, this might be a viable fix, and quite efficient.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div>
2) Optimize the DWARF size.<br></div></div></div></div></div></div></blockquote><div><br>Do your users care much about this? I imagine if they had significant DWARF size issues, they'd have significant link time issues and the kind of cost to link time this feature has would be prohibitive - but perhaps they're sharing linked binaries much more often than they're actually performing linking.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div>
<br>
The specifics which our users have:<br>
- embedded platform which uses 0 as start of .text section. <br>
- custom toolset which does not support all features yet(f.e. split dwarf).<br>
- tolerant of the link-time increase.<br>
- need a useful way to share debug builds. <br></div></div></div></div></div></div></blockquote><div><br>Sharing two files (executable and dwp) is significantly less useful than sharing one file? <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div>
<br>
For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553).</div>
<div>We use custom solution, but the general solution like D74169 would be better here.<br></div></div></div></div></div></div></blockquote><div><br></div><div>If CU ranges are the only ones that need fixing, then I think the above solution might be as good/better - if more than CU ranges need fixing, then I think we might want to start talking about how to fix DWARF itself (split and non-split) to signal certain addresses point to dead code with a specific blessed value that linkers would need to implement - because with Split DWARF there's no way to solve the non-CU addresses at the linker.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div>For the second point: split dwarf could be a good alternative to have debug info with minimal size.
</div>
<div>Still, it has drawbacks (not supported by tools currently, does not solve the "Overlapping address ranges"
</div>
<div>problem, not very convenient to share(even using .dwp)).<br>
<br>
Thus in long terms, the D74169 looks to be a good solution for us: resolves "Overlapping address ranges"
</div>
<div>problem, binary with minimal size, supported by current tools, easy to share debug build(single binary with
</div>
<div>minimal size).<br>
</div>
<div><br>
> In general, in the current state, I don't have strong feelings either way about this going in as-is with the intent to >improve it to make it more viable - or some of that work being done out-of-tree until it's a more viable >performance tradeoff. Mostly
happy to leave that up to folks more involved with lld.<br>
><br>
>A couple of minor points...</div>
<br>
<div class="gmail_quote">
<div><span style="font-family:"Courier New",monospace">>> C: --function-sections --gc-sections --fdebug-types-section<br>
</span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div>> ^ not sure of the point of testing/showing comparisons with a situation that's currently unsupported</div>
<div><br>
</div>
<div><br>
</div>
<div>that situation is currently supported(--gc-debuginfo is not used in this measurement).<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>Ah, I was confused because it looks like/the description said it was... </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote"><div>
"--fdebug-types-section" is supported functionality.<br>
The purpose of these data is to compare results for "--fdebug-types-section" and "--gc-debuginfo".</div></div></div></div></div></div></div></blockquote><div><br>OK<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
<p>>>2. Support of type units.</p>
<p><br>
>> That could be implemented further.<br>
</p>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div>>Enabling type units increases object size to make it easier to deduplicate at link time by a DWARF-unaware
</div>
<div>>linker. With a DWARF aware linker it'd be generally desirable not to have to add that object size overhead to
</div>
<div>>get the linking improvements. </div>
<div><br>
</div>
<div>But, DWARFLinker should adequately work with type units since they are already implemented.</div></div></div></div></div></div></div></blockquote><div><br>Maybe - it'd be nice & all, but I don't think it's an outright necessity - if someone knows they're using a DWARF-aware linker, they'd probably not use type units in their object files. It's possible someone doesn't know for sure & maybe they have pre-canned debug object files from someone else, etc.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote">
<div>If someone uses --fdebug-types-section, then it should adequately work when used together
</div>
<div>with --gc-debuginfo(if --gc-debuginfo would be accepted).</div>
<div>Right?<br>
<br>
Another thing is that the idea behind type units has the potential to help Dwarf-aware linker to work faster.</div>
<div>Currently, DWARFLinker analyzes context to understand whether types are the same or not.</div></div></div></div></div></div></div></blockquote><div><br></div><div>When you say "analyzes context" what do you mean? Usually I'd take that to mean "looks at things outside the type itself - like what namespace it's in, etc" - which, yes, it should do that, but it doesn't seem very expensive to do. But I guess you actually mean something about doing structural equivalence in some way, looking at things inside the type?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote"><div>
</div>
<div>But the context is known when types are generated. So, no need to spent the time analyzing it.
</div>
<div>If types could be compared without analyzing context, then Dwarf-aware linker would work faster.</div>
<div>That is just an idea(not for immediate implementation): If types would be stored in some "type table"
</div>
<div>(instead of COMDAT section group) and could be accessed through hash-id(like type units)
</div>
<div>- then it would be the solution requiring fewer bits to store but allowing to compare types
</div>
<div>by hash-id(not analysing context). <br>
In this case, size increasing would be small. And processing time could be done faster.<br>
<br>
this is just an idea and could be discussed separately from the problem of integrating of D74169.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
<p>>>4. split DWARF support.</p>
<p><br>
>> This solution does not work with split DWARF currently. But it could be useful for the split dwarf in two ways:<br>
>> a) The generation of skeleton file could be changed in such a way that address ranges pointing to garbage
</p>
<p>>> collected code would be replaced with lowpc=0, highpc=0. That would solve the problem of overlapping
</p>
<p>>> address ranges(D59553). </p>
<p><br>
</p>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div>>This wouldn't/couldn't completely address the issue - because some address ranges would be in the .dwo files >the linker can't see - and they'd still end up with the interesting address ranges.</div>
<div><br>
</div>
<div>I see, Thank you. Thus it would not be a complete solution.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
<p>>> 6. -flto=thin</p>
<p><br>
>> That problem was described in this review <a href="https://reviews.llvm.org/D54747#1503720" target="_blank">
https://reviews.llvm.org/D54747#1503720</a>. It also exists in </p>
<p>>> current DWARFLinker/dsymutil implementation. I think that problem should be discussed more: it could
</p>
<p>>> probably be fixed by avoiding generation of such incomplete declaration during thinlto,
</p>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
</div>
</blockquote>
<div>>> That would be costly to produce extra/redundant debug info in ThinLTO - actually ThinLTO could be doing
</div>
<div>>> more to reduce that redundancy early on (actually removing definitions from some llvm Modules if the type
</div>
<div>>> definition is known to exist in another Module, etc)<br>
<br>
>I don't know if it's a problem since that patch was reverted.</div>
<div><br>
</div>
<div>Yes. That patch was reverted, but this patch(D74169) has the same problem. </div>
<div>if D74169 would be applied and --gc-debuginfo used then structure type </div>
<div>definition would be removed.<br>
<br>
DWARFLinker could handle that case - "removing definitions from some llvm Modules if the type</div>
<div>definition is known to exist in another Module". <br>
i.e. DWARFLinker could replace the declaration with the definition.<br>
<br>
But that problem could be more easily resolved when debug info is generated(probably without
<br>
significant increase of debug info size): <br>
<br>
Let`s check the example:<br>
<br>
<span style="font-family:"Courier New",monospace">0x0000000b: DW_TAG_compile_unit</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_low_pc (0x0000000000201700)</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_high_pc (0x0000000000201719)</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x0000002a: DW_TAG_subprogram</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000043: DW_TAG_inlined_subroutine</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_abstract_origin (0x0000000000000086 "_Z1fv")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_low_pc (0x0000000000201700)</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_high_pc (0x0000000000201718)</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000057: DW_TAG_variable</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_abstract_origin (0x0000000000000096 "var")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000065: NULL</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000073: DW_TAG_compile_unit</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_stmt_list (0x00000080)</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000086: DW_TAG_subprogram</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("f")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_inline (DW_INL_inlined)</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000096: DW_TAG_variable</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("var")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_type (0x000000a9 "volatile Foo")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x000000a1: NULL</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x000000a9: DW_TAG_volatile_type</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_type (0x000000ae "Foo")</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x000000ae: DW_TAG_structure_type </span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("Foo")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_declaration (true)</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x000000c1: DW_TAG_compile_unit</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_low_pc (0x0000000000000000)</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_high_pc (0x0000000000000019)</span><br style="font-family:"Courier New",monospace">
</div>
<div><br>
</div>
<div><span style="font-family:"Courier New",monospace">0x000000e0: DW_TAG_subprogram</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_low_pc (0x0000000000000000)</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_high_pc (0x0000000000000019)</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("f")</span></div>
<div><br style="font-family:"Courier New",monospace">
</div>
<div><span style="font-family:"Courier New",monospace">0x000000fd: DW_TAG_variable</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("var")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_type (0x00000119 "volatile Foo")</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x00000119: DW_TAG_volatile_type</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_type (0x0000011e "Foo")</span><br>
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">0x0000011e: DW_TAG_structure_type</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_name ("Foo")</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace"> DW_AT_decl_line (1)</span><br style="font-family:"Courier New",monospace">
<br>
Here we have:<br>
<br>
DW_TAG_compile_unit(0x0000000b) - compile unit containing concrete instance for function "f".<br>
DW_TAG_compile_unit(0x00000073) - compile unit containing abstract instance root for function "f".<br>
DW_TAG_compile_unit(0x000000c1) - compile unit containing function "f" definition.<br>
<br>
Code for function "f" was deleted. gc-debuginfo deletes compile unit DW_TAG_compile_unit(0x000000c1)
</div>
<div>containing "f" definition (since there is no corresponding code). But it has structure "Foo" definition
</div>
<div>DW_TAG_structure_type(0x0000011e) referenced from DW_TAG_compile_unit(0x00000073)</div>
<div>by declaration DW_TAG_structure_type(0x000000ae). That declaration is exactly the case when definition
</div>
<div>was removed by thinlto and replaced with declaration.<br>
<br>
Would it cost too much if type definition would not be replaced with declaration for "abstract instance root"?
</div>
<div>The number of concrete instances is bigger than number of abstract instance roots.
</div>
<div>Probably, it would not be too costly to leave definition in abstract instance root?</div></div></div></div></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote"><div>Alternatively, Would it cost too much if type definition would not be replaced with declaration when declaration references type from not used function? (lto could understand that concrete function is not used).<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>I don't follow this example - could you provide a small concrete test case I could reproduce?<br><br>Oh, I guess this is happening perhaps because ThinLTO can't know for sure that a standalone definition of 'f' won't be needed - so it produces one in case one of the inlining opportunities doesn't end up inlining. Then it turns out all calls got inlined, so the external definition wasn't needed.<br><br>Oh, you're suggesting that these 3 CUs got emitted into one object file during LTO, but that DWARFLinker drops a CU without any code in it - even though... So far as I know, in LTO, LLVM directly references types across units if the CUs are all emitted in the same object file. (and if they weren't in the same object file - then the abstract_origin couldn't be pointing cross-CU).<br><br>I guess some basic things to say:<br><br>With ThinLTO, the concrete/standalone function definition is emitted in case some call sites don't end up being inlined. So we know it'll be emitted (but might not be needed by the actual linker)<br>ANy number of inline calls might exist - but we shouldn't put the type information into those, because they aren't guaranteed to emit it (if the inline function gets optimized away, there would be nothing to enforce the type being emitted) - and even if we forced the type information to be emitted into one object file that has an inline copy of the function - there's no guarantee that object file will get linked in either.<br><br>So, no, I don't think there's much we can do to keep the size of object files down, while guaranteeing the type information will be emitted with the usual linker semantics.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(33,33,33)"><div><div><div dir="ltr"><div class="gmail_quote"><div>
<br>
</div>
<div><br>
</div>
<div>Thank you, Alexey.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:Calibri,Arial,Helvetica,sans-serif">
<p class="MsoNormal"><font size="1"><span style="font-size:11pt;font-family:"Trebuchet MS",sans-serif;color:black"></span></font></p>
<div id="m_-9201951770311992896gmail-m_-8966064977305553731gmail-m_9019961954974587019Signature">
<div name="divtagdefaultwrapper">
<table cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:0.75pt" valign="top"><br>
</td>
<td style="padding:0.75pt"><br>
</td>
</tr>
</tbody>
</table>
<br>
<font size="2"><span style="font-size:11pt;font-family:"Trebuchet MS",sans-serif;color:black"></span></font></div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div>