[LLVMdev] Debug Info and MergeFunctions Transform
dblaikie at gmail.com
Tue Oct 14 13:40:41 PDT 2014
On Sun, Oct 12, 2014 at 2:02 AM, <llvm at dyatkovskiy.com> wrote:
> 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".
I don't think that's completely unreasonable - actually it's probably about
the most right thing we can do (in this way the user would've seen "caller
-> G -> etc... " and will now see "caller -> G -> F -> etc..." which might
be a bit confusing, but that's the nature of optimization, really).
Do you have a small C++/clang example of function merging firing, and using
> 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
Yeah, I suspect we'd confuse debug info consumers if we produced two
function descriptions describing the same function... for a bunch of
reasons (& adding the plumbing to do that in LLVM's debug info emission
wouldn't be easy either) so I'll probably leave that alone for now.
> 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
> >> 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
> >> 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
> >> can have the debug info for one function reference a global alias,
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev