<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 30, 2017 at 12:15 PM Gor Nishanov <<a href="mailto:gornishanov@gmail.com">gornishanov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am thinking as llvm gets more sophisticated outlining facilities where parts of function could be extracted into separate functions to help with inlining, vectorization, openmp, exceptions, etc, coroutines won't remain unique. From the debugging experience, it is still the original function, just split up into more than one for some only optimizer known reason :)</div></blockquote><div><br>Sure - bit more complicated than that, though (I mean any function cloning is). As I was talking with Richard about this the other day, some thoughts:<br><br>If the user asks to break on the function - does that break on all of the coroutine fragments? (ie: every time you enter the function, not just when you enter at the start of the function)<br>What's the function name in a backtrace, if you're in a fragment of the function - if it's just the plain function name might that be confusing to users, since there's no call to the function from the caller, exactly? (I mean there's lots of implicit operations in C++, so maybe that's not totally bad)<br><br>& presumably calls to the function (or taking its address, etc) in a debugger expression evaluator should only find the original function, not the fragments...<br><br>(& the more complicated part: getting the variable locations right - that'll take some more work going through the dynamically allocated frame block, etc)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 30, 2017 at 10:46 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Tue, May 30, 2017 at 8:17 AM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl accepted this revision.<br>
aprantl added a comment.<br>
This revision is now accepted and ready to land.<br>
<br>
Thanks Keno, this appears to be a far better approach. The only question that remains is whether / how to update the linkage name of the cloned DISubprogram. But I don't think that this needs to be solved in this patch.<br></blockquote></span><div><br>*nod* Agreed.<br><br>Speculating rampantly: I wonder if it'd make sense to remove the linkage name from definitions and use the actual Function's linkage name (hmm, that doesn't work for inlining, though - so maybe it does have to be duplicated when the function is cloned - but could then have a verifier/invariant that it matches the Function if there is one). And then even allow the mangled name to differ between declaration and definition - and put an extra DW_AT_linkage_name on the definition if it's different from the declaration.<br><br>*shrug* Don't really know. The right answers may require thinking a fair bit about the coroutines debug info as a (perhaps somewhat unique) example of cloning, etc.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="https://reviews.llvm.org/D33655" rel="noreferrer" target="_blank">https://reviews.llvm.org/D33655</a><br>
<br>
<br>
<br>
</blockquote></div></div>
</blockquote></div><br></div>
</blockquote></div></div>