similar to: Debuggability of -O1 level

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

(Remembering to +llvm-dev this time…) There has been some progress in the direction of improving debuggability of optimized code, in the past year. There have been a number of patches to improve tracking of debug info in various passes, and some more general improvements such as work on the LiveDebugValues pass. I don't think anyone has done a specific analysis to identify passes that lose

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

> > > > - Dead code elimination (ADCE, BDCE) > > > Regarding BDCE: The trivialized values might indeed be irrelevant to > later calculations, but might harm the debugging experience? If BDCE > only was applied at O2 and higher, that's likely not a huge loss. > Regular DCE (meaning without the bit-tracking parts) is probably fine > for O1. > > >

Awesome start. Back when I did a similar project at HP/NonStop, the class of optimizations we turned off for our O1 (Og equivalent) tended to be those that reordered code or otherwise messed with the CFG. In fact one of our metrics was: - The set of breakpoint locations available at Og should be the same as those available at O0. This is pretty easy to measure. It can mean either turning

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

+ 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

Mhm I see now, thanks for your explanation! Son Tuan Vu On Fri, Mar 16, 2018 at 10:58 PM, Vedant Kumar <vsk at apple.com> wrote: > > On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but > I guess this is reserved for your GSoC project ? > >

Hi All, I’ve been thinking about both O1 and Og optimization levels and have a proposal for an improved O1 that I think overlaps in functionality with our desires for Og. The design goal is to rewrite the O1 optimization and code generation pipeline to include the set of optimizations that minimizes build and test time while retaining our ability to debug. This isn’t to minimize efforts around

> On Apr 20, 2018, at 1:46 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > 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 <mailto:vsk at apple.com>> wrote: > Hi, > > + Chandler, who has a lot more experience with our pass managers.

Hi Vedant, Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of

> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project.

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 Debugify is also related? Could you clarify the question? I'm not sure what it is you'd like me to chime in about. > 2, I've asked this question once but

Hi Vedant, hi all, My goal is to measure debug info loss of *each* optimization pass in LLVM. I am trying to create a debugify-each mode in opt, inspired by verify-each mode which is supposed to already work. However, if I understand correctly, the verify-each mode (triggered by -verify-each option in opt) only works when we provide a pass list or a pass pipeline. Is this intended? I mean, why

Hi Vedant, I have tried to implement the fix you proposed, but it didn't work as expected. I created a new *Module* Pass Manager (not Function Pass Manager) and override the *add()* method like this: class DebugifyEachPassManager : public legacy::PassManager { public: void add(Pass *P) override { PassManager::add(createDebugifyPass()); PassManager::add(P);

Hello, > On Apr 26, 2018, at 6:44 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > I have tried to implement the fix you proposed, but it didn't work as expected. I created a new Module Pass Manager (not Function Pass Manager) and override the add() method like this: > > class DebugifyEachPassManager : public legacy::PassManager { >

We thought about putting the 'this' pointer into memory but that would mean that even small member functions would acquire a stack frame (on architectures where leaf routines can get away without one), which may degrade performance considerably. You could apply some heuristics and determine when a store is unnecessary, but inlining may complicate things. A fake_use operation would be

Hi Son Tuan, Thanks for taking a look at this :). Responses inline -- > On Mar 14, 2018, at 8:11 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, hi all, > > My goal is to measure debug info loss of each optimization pass in LLVM. I am trying to create a debugify-each mode in opt, inspired by verify-each mode which is supposed to already work. +

When I worked on the HPE NonStop compilers for x86 (we used Open64, not LLVM), we adjusted our -O1 to make sure the source display didn't "bounce around" based on feedback from users. We disabled any optimization that would move things across statement boundaries. We also disabled/de-tuned dead store since our DWARF location list support was pretty basic and with the removed store,