[PATCH] D33655: [Cloning] Take another pass at properly cloning debug info

[Gor Nishanov via llvm-commits]

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 :)

On Tue, May 30, 2017 at 10:46 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, May 30, 2017 at 8:17 AM Adrian Prantl via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> aprantl accepted this revision.
>> aprantl added a comment.
>> This revision is now accepted and ready to land.
>>
>> 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.
>>
>
> *nod* Agreed.
>
> 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.
>
> *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.
>
>
>>
>>
>> https://reviews.llvm.org/D33655
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170530/fee212d2/attachment.html>