search for: measuring_the_user_debugging_experi

...ying to decouple the expected-behaviour language from the debugger-abstractions summary of how the program behaved. [0] https://reviews.llvm.org/D54187#1290282 [1] https://github.com/SNSystems/dexter [2] https://www.youtube.com/watch?v=XRT_GmpGjXE [3] https://llvm.org/devmtg/2018-04/slides/Bedwell-Measuring_the_User_Debugging_Experience.pdf [4] https://github.com/jmorse/dexter/tree/f46f13f778484ed5c6f7bf33b8fc2d4837ff7265/tests/nostdlib/llvm_passes [5] https://github.com/llvm/llvm-project/tree/master/debuginfo-tests -- Thanks, Jeremy

Generally, a good strategy is to look at what Clang generates for similar code and mimic that in your IR generator. -- adrian

...we can get that matches such an aim, but once we've decided what -Og should mean, I'd like to try and justify any changes with some real data. I'm willing for my team to contribute as much data as we can. We've also been using dexter [ http://llvm.org/devmtg/2018-04/slides/Bedwell-Measuring_the_User_Debugging_Experience.pdf ] to target our -O2 debugging improvement work, but hopefully it will be useful to provide another datapoint for the effects on the debugging experience of disabling specific passes. In my mind, -Og probably would incorporate a few things: * Tweak certain pass behaviors in order to be more...

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