search for: debugifi

...tats after each pass and dump them as JSON, at the end of the pipeline. > > vedant > > >> Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass? >> >> Thank you for your help, >> >> Son Tuan Vu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180316/60d7042b/attachment.html>

...er each pass and dump them as JSON, at the > end of the pipeline. > > vedant > > > Maybe writing a script that collects all optimization options (like > -mem2reg or -constmerge), then pass each one of them to opt with > -enable-debugify so that we have 1 output file for each debugified pass? > > Thank you for your help, > > Son Tuan Vu > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180316/17f779d5/attachment.html>

...ON, at the >> end of the pipeline. >> >> vedant >> >> >> Maybe writing a script that collects all optimization options (like >> -mem2reg or -constmerge), then pass each one of them to opt with >> -enable-debugify so that we have 1 output file for each debugified pass? >> >> Thank you for your help, >> >> Son Tuan Vu >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180316/c5a45eb4/attachment.html>

...at should be the best way to debugify each pass? Adding a debugify-each mode would make the output unreadable! Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass? Thank you for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180314/b4a78210/attachment.html>

...and dump them as JSON, at the end of the pipeline. >> >> vedant >> >> >>> Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass? >>> >>> Thank you for your help, >>> >>> Son Tuan Vu >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180426/8f011ce2/attach...

...he pipeline. >>> >>> vedant >>> >>> >>> Maybe writing a script that collects all optimization options (like >>> -mem2reg or -constmerge), then pass each one of them to opt with >>> -enable-debugify so that we have 1 output file for each debugified pass? >>> >>> Thank you for your help, >>> >>> Son Tuan Vu >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201...

...; >>>> vedant >>>> >>>> >>>> Maybe writing a script that collects all optimization options (like >>>> -mem2reg or -constmerge), then pass each one of them to opt with >>>> -enable-debugify so that we have 1 output file for each debugified pass? >>>> >>>> Thank you for your help, >>>> >>>> Son Tuan Vu >>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:/...

...e should capture these stats after each pass and dump them as JSON, at the end of the pipeline. vedant > Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass? > > Thank you for your help, > > Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180314/5459d9ae/attachment.html>

Hi Vedant, Thanks a lot for your comments! >It looks like a lot of the new infrastructure introduced here <https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27> consists of logic copied from the debugify implementation. Why is introducing a new pair of passes better than extending the ones we have? The core infrastructure needed to track

Hi, I am sharing the proposal [0] which gives a brief introduction for the implementation of the LLVM DI Checker utility. On a very high level, it is a pair of LLVM (IR) Passes that check the preservation of the original debug info in the optimizations. There are options controlling the passes, that could be invoked from ``clang`` as well as from ``opt`` level. By testing the utility on the

Hello all, I came across the code of Verifier, and see that it doesn't modify the IR at all. Why it is not considered as an analysis pass? Actually, this will have impact on debugify-each and print-before/after-all: we are not supposed to print/debugify Verifier pass, but since Verifier is declared as a transformation (well, a non-analysis) pass, we actually do print/debugify it. Thanks for

Hi, I'm not sure which passes exactly drop debug info, but it's likely that most of them do. If you're interested in working on this problem, I suggest experimenting with the debugify utility in opt. This tool can be used to identify passes which drop debug info and to generate targeted/reduced test cases for specific problems. To use it, you can add the '-enable-debugify'

Hello Paul, François and Vedant, Thank you all for your answers. And sorry for this late reply. I wanted to dig more into the LLVM source code to get a better understanding of the debug part of it before replying/asking more questions. I have came across this https://llvm.org/docs/SourceLevelDebugging.html#debugging-optimized-code which stated that "*Basically, the debug information allows

My experience is that just running mem2reg (while disabling virtually all other passes ) in O1 will substantially improve debuggability while giving acceptable performance. On Mon, Jan 29, 2018 at 11:39 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > (Remembering to +llvm-dev this time…) > > > > There has been some progress in the direction of improving debuggability

Hi, I've prototyped a pair of passes which 1) add synthetic debug info to a Module and 2) determine how much of that info is lost. The idea is to make it easier to write targeted test cases for debug info preservation. For example, here is a quick way to test that Mem2Reg doesn't drop debug info from one test input: > ; RUN: opt < %s -debugify -mem2reg -check-debugify -S

Hello, I'm an undergraduate student in the CS department of Aristotle University of Thessaloniki (AUTh). Last year I successfully completed GSoC with Mixxx [1] and this year I would like to work on LLVM. I am interested in "Improving debugging of optimized code" [2]. I have gone through the kaleidoscope tutorial and I've set up a basic dev environment for LLVM and clang.

> On May 30, 2018, at 8:37 AM, Anast Gramm <anastasis.gramm2 at gmail.com> wrote: > > Introduction > ============ > > `SROA' is an early stage pass running at the very beginning of the > pipeline in `-O{1,2,3}'. Greg Bedwell's report from his DExTer tool > shows SROA on function as one of the major culprits of Debug Info > loss. > > With

+ Vedant: what do you think about the last point, since Debugify is also related? Son Tuan Vu On Thu, Apr 19, 2018 at 6:14 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Son, > > PassManagerBuilder is used to populate legacy PassManagers. That role is > taken over by PassBuilder for new-PM passes. > > Cheers, > Philip > > 2018-04-18 13:40 GMT+02:00

Hi Vedant, Thanks for your reply. More comments inline. Son Tuan Vu On Fri, Apr 20, 2018 at 10:19 PM, Vedant Kumar <vsk at apple.com> wrote: > Hi, > > + Chandler, who has a lot more experience with our pass managers. > > On Apr 20, 2018, at 12:56 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > + Vedant: what do you think about the last point, since

Hi Anastasis, Welcome, and congratulations! It's great to see that you're maintaining a devlog and have hit the ground running. I'm looking forward to working with you. > On Apr 25, 2018, at 12:56 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Welcome Anastasis! I'm very happy to see this work going forward. > > I see that your first task is to