[PATCH] D40778: [DebugIR] Revive the Debug IR pass. [Added llvm-commits]

Vedant Kumar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 4 14:01:32 PST 2017


vsk added a comment.

In https://reviews.llvm.org/D40778#944173, @Ralith wrote:

> In https://reviews.llvm.org/D40778#944145, @vsk wrote:
>
> > In https://reviews.llvm.org/D40778#944139, @Ralith wrote:
> >
> > > Personally, I'm usually debugging JITd code, so there is no natural *.ll file on disk, and at no point is IR parsed from text. It's my understanding that debuggers do generally expect a source file to exist, but it would still be more natural for me to generate the source file on the side, rather than writing it out and then immediately using it to reconstruct the module.
> >
> >
> > I don't think this use case would be supported unless -debugir would always be a part of the JIT pipeline. If debugging needs to be enabled by a special flag, it would be simple enough to implement it by invoking llvm-as on M.dump(). Implementing -debugir in the LL reader has other advantages, e.g it allows you to mark up the LL file with comments or edit it, then re-compile & debug again.
>
>
> To be clear, I'm not using the off-the-shelf JIT pipeline, but rather generating code and wrangling RuntimeDyld and friends myself. Hence, a pass would work well for me. While your proposed approach could be made to work for my case, it would be significantly less convenient, and would not let me take advantage of any opportunity to add comments to IR for debugging convenience (although I have never felt any need to do so).


Calling 'parseIR(..., EnableDebugIR=true)->print(OS)' before the running the program seems reasonable, though I admit I don't know how messy this might be in your use case. The alternative is to *not* support -debugIR on marked-up *.ll files, which seems worse.


https://reviews.llvm.org/D40778





More information about the llvm-commits mailing list