[PATCH] DebugIR: Delete old debug info instead of updating it

Eric Christopher echristo at gmail.com
Mon Nov 24 10:32:52 PST 2014


On Mon Nov 24 2014 at 9:08:36 AM David Blaikie <dblaikie at gmail.com> wrote:

> Honestly, debugir seemed like it went in half-baked and has rotted a bit
> since then. I'd probably advocate for removing it at this point - someone
> can resurrect it when they have time/care to more fully test it, etc. (the
> fact that you can remove this code without tests failing (I assume you
> tested that) is an indication that it's not well tested, etc)
>
>
It was in a little better shape than that when it went in. It had some
basic functionality and someone to maintain it... and then their project
was canceled :\

That said, I'm also ok with removing it.

-eric


> On Sun, Nov 23, 2014 at 7:26 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
>
>> While removing instances of `MDNode::replaceAllUsesWith()`, I came
>> across this unlikely-to-be-correct RAUW of a compile unit.
>>
>> There are no tests that the updated debug info works correctly and it
>> looks unlikely to be useful in any way -- are you debugging the original
>> source, or the IR?  Instead, just delete the old debug info before
>> creating something new.
>>
>
> I can imagine this could be useful - it's a slightly dodgy way to
> propagate flags down from a frontend into the debugir. "Optimized" for
> example, is meaningful even to debugIR (& the value that Clang sets would
> be generally correct - it does cause LLVM to run more optimizations, etc).
> SplitDebugFilename would also be relevant - if your frontend has enabled
> fission, not propagating this attribute would produce a weird result (the
> frontend would split out the .dwo sections, but they would be empty - at
> best this would produce a very uninteresting .dwo file, at worst, objdump
> might fail because there were no sections to move out).
>
> But *shrug* Really dunno what to do with all this code.
>
>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141124/9c42195e/attachment.html>


More information about the llvm-commits mailing list