llvm dev - Oct 2014 - [LLVMdev] Debug Info and MergeFunctions Transform

Hi Stepan,

After discovering several bugs in ArgumentPromotion and
DeadArgumentElimination where llvm::Functions were replaced with similar
functions (with the same name) to transform their type in some way, I
started looking at all calls to llvm::Function::takeName to see if there
were any other debug info quality bugs in similar callers.

One such caller is MergeFunctions, and I don't see any debug info tests for
this so I'm wondering what /should/ happen here.

In the case where the functions are internal I'm not sure there's
anything
we can do, we simply remove one function and keep the other - the debug
info can only be ascribed to one of the two and this probably comes out
naturally (whichever name we choose to keep). I don't think we can have the
debug info for one function reference a global alias, while the debug info
for another function references the thing that alias refers to. So be it.

But in the case of MergeFunctions::writeThunk we can probably do better -
by updating the debug info for the thunk'd function so we at least describe
this trivial function in the debug info.

Does that sound about right?

Could you provide any C/C++ source examples where MergeFunctions fires
fairly reliably so I could play around with the debug info behavior (&
fixes) here?

Thanks,
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/012cf12a/attachment.html>

Hi David,
Thanks for attention to MergeFunctions! I have read your mail briefly, 
tomorrow I'll provide you with detailed information. By now you could 
use tests from  $LLVM/test/Transforms/MergeFunc/ as examples.

Cheers!
-Stepan

David Blaikie wrote:
> Hi Stepan,
>
> After discovering several bugs in ArgumentPromotion and
> DeadArgumentElimination where llvm::Functions were replaced with similar
> functions (with the same name) to transform their type in some way, I
> started looking at all calls to llvm::Function::takeName to see if there
> were any other debug info quality bugs in similar callers.
>
> One such caller is MergeFunctions, and I don't see any debug info tests
> for this so I'm wondering what /should/ happen here.
>
> In the case where the functions are internal I'm not sure there's
> anything we can do, we simply remove one function and keep the other -
> the debug info can only be ascribed to one of the two and this probably
> comes out naturally (whichever name we choose to keep). I don't think
we
> can have the debug info for one function reference a global alias, while
> the debug info for another function references the thing that alias
> refers to. So be it.
>
> But in the case of MergeFunctions::writeThunk we can probably do better
> - by updating the debug info for the thunk'd function so we at least
> describe this trivial function in the debug info.
>
> Does that sound about right?
>
> Could you provide any C/C++ source examples where MergeFunctions fires
> fairly reliably so I could play around with the debug info behavior (&
> fixes) here?
>
> Thanks,
> - David

Hi David,

After merging we always remove body of "G" (function we want to merge
with "existing" one).
In case with "writeThunk" we could add such info for "G",
but it would be just a single string: reference to first string of
"G".

Ideal way here, is to merge debug information itself, and provide "F"
with information for "G" and "F", but I think it's
unreal :-( Since debugger should check function name it entered, and then filter
such debug information with this name. Though I'm not that familiar with
Debug Info, perhaps there are still possible ways to provide single body with
two debug infos.

-Stepan

08.10.2014, 00:32, "Stepan Dyatkovskiy" <stpworld at
narod.ru>:
> Hi David,
> Thanks for attention to MergeFunctions! I have read your mail briefly,
> tomorrow I'll provide you with detailed information. By now you could
> use tests from  $LLVM/test/Transforms/MergeFunc/ as examples.
>
> Cheers!
> -Stepan
>
> David Blaikie wrote:
>>  Hi Stepan,
>>
>>  After discovering several bugs in ArgumentPromotion and
>>  DeadArgumentElimination where llvm::Functions were replaced with
similar
>>  functions (with the same name) to transform their type in some way, I
>>  started looking at all calls to llvm::Function::takeName to see if
there
>>  were any other debug info quality bugs in similar callers.
>>
>>  One such caller is MergeFunctions, and I don't see any debug info
tests
>>  for this so I'm wondering what /should/ happen here.
>>
>>  In the case where the functions are internal I'm not sure
there's
>>  anything we can do, we simply remove one function and keep the other -
>>  the debug info can only be ascribed to one of the two and this
probably
>>  comes out naturally (whichever name we choose to keep). I don't
think we
>>  can have the debug info for one function reference a global alias,
while
>>  the debug info for another function references the thing that alias
>>  refers to. So be it.
>>
>>  But in the case of MergeFunctions::writeThunk we can probably do
better
>>  - by updating the debug info for the thunk'd function so we at
least
>>  describe this trivial function in the debug info.
>>
>>  Does that sound about right?
>>
>>  Could you provide any C/C++ source examples where MergeFunctions fires
>>  fairly reliably so I could play around with the debug info behavior
(&
>>  fixes) here?
>>
>>  Thanks,
>>  - David
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev