(original) (raw)
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
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