
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 19, 2020, at 3:03 PM, Vedant Kumar <<a href="mailto:vedant_kumar@apple.com" class="">vedant_kumar@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">In a recent review (<a href="https://reviews.llvm.org/D79967" class="">https://reviews.llvm.org/D79967</a>), David Blaikie suggested that we have a broader design discussion about how support for DW_TAG_call_site is supported in clang, so I’ll kick off the discussion.</div><div class=""><br class=""></div><div class="">Some topics to discuss:</div><div class=""><br class=""></div><div class="">1) Under LTO, if we emit a declaration DISubprogram for a function in one TU, and another TU defines the function with __attribute__((nodebug)), would the declaration DISubprogram get attached to the definition?</div><div class=""><br class=""></div><div class="">My own thoughts on this: firstly, as posed in <a href="https://reviews.llvm.org/D79967" class="">D79967</a>, I think David was asking about the case where the declaration subprogram does not have an attached unit. I’m not sure why it wouldn’t, though, so I’d appreciate some clarification on that. Second, as far as I know, there isn’t a mechanism for attaching a declaration subprogram to a Function which doesn’t have debug info.</div><div class=""><br class=""></div><div class="">2) Should declaration subprograms emitted in support of DW_TAG_call_site be kept in the CU’s retainedTypes field?</div><div class=""><br class=""></div><div class="">David pointed out that these declarations a) persist through optimization and b) don't get deduplicated against the definitions, which means there’s potential to bloat debug info. As an alternative, we might attach a declaration subprogram to the corresponding Function (which we do already), but leave it out of the CU’s retainedTypes field.</div></div></div></blockquote><div><br class=""></div><div>I'm having trouble visualizing this example: We are talking about forward declaration DISubprograms created for call sites of functions that are not defined in the CU where the call site is, correct? What does "attaching a declaration to the corresponding function" mean? Why are we currently entering those declarations into retainedTypes? I would have expected the reference from the call site to hold on to them. I guess it's unclear to me how call sites are represented at the moment.</div><div><br class=""></div><div>-- adrian</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">My own thoughts: as I understand it, if a function ends up dead (all call sites to it are optimized out), we won’t emit a DW_TAG_call_site that references the function, and so we won't emit unnecessary declaration subprograms. This is demonstrated in the LTO case in llvm/test/DebugInfo/X86/lto-cross-cu-call-origin-ref.ll (added in <a href="https://reviews.llvm.org/D70350" class="">https://reviews.llvm.org/D70350</a>), where the declaration subprograms for func_from_b, noinline_func_in_a, and always_inline_helper_in_a_that_calls_foo are elided. The same test demonstrates that llvm can emit cross-CU references to definition subprograms within DW_TAG_call_site. However, all of this just pertains to the final DWARF. There may still be some cost (in terms of metadata) to preserving a declaration subprogram throughout optimization when all references to the declaration are removed. Before changing the representation, it’d be helpful to measure how much it costs (either in terms of compile-time, or metadata size) to keep unreferenced declaration subprograms around (say, on a stage2 clang build).</div><div class=""><br class=""></div><div class="">As for why declaration subprograms are inserted into a CU’s retainedTypes field in the first place: I don’t think this was intentionally changed just for DW_TAG_call_site support. Adrian (cc’d) changed EmitFunctionDecl to retain declaration subprograms in r266445, and the new code path which calls into EmitFunctionDecl adopted the same behavior. (Hopefully that clears up some of the history, that’s not to say that it’s not worth revisiting.)</div><div class=""><br class=""></div><div class="">best,</div><div class="">vedant</div></div></div></blockquote></div><br class=""></body></html>