search for: pieb

...ot to reply-all (& adding a few other people to the 'to' line) ---------- Forwarded message ---------- From: David Blaikie <dblaikie at gmail.com> Date: Mon, Sep 21, 2015 at 11:22 AM Subject: Re: [llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode To: "Pieb, Wolfgang" <Wolfgang_Pieb at playstation.sony.com> On Mon, Sep 21, 2015 at 11:16 AM, Pieb, Wolfgang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello! > > > > At Sony we've seen some serious customer interest in having the 'this' > pointer...

...iables as well. This 'this' pointer Is invariant, but other parameters and locals are generally not, so we believe extending the live range would be a more general solution. -- wolfgang From: Smith, Kevin B [mailto:kevin.b.smith at intel.com] Sent: Monday, September 21, 2015 7:12 PM To: Pieb, Wolfgang Cc: llvm-dev at lists.llvm.org Subject: RE: extending liveness of 'this' pointer via FAKE_USE opcode Why extend the live-range? If it isn't already in memory (and for many architectures, it is already in memory), put the this pointer into memory, and change the debug informa...

Hello! At Sony we've seen some serious customer interest in having the 'this' pointer visible throughout an entire function during debugging. However, optimizations may eliminate it after its last use, so we've been looking for a way to artificially extend its liverange to the end of the function. So far, the most compelling way we can think of, and one we have used successfully

...> want to take advantage of that. > > Let me know if you have any more questions. > > Cheers, > Wolfgang > > > -----Original Message----- > > From: Victor Leschuk [mailto:vleschuk at accesssoftek.com] > > Sent: Thursday, July 12, 2018 2:24 AM > > To: Pieb, Wolfgang; LLVM Dev > > Cc: aprantl at apple.com; David Blaikie > > Subject: debug_rnglists status > > > > Hello Wolfgang and team, > > > > I see that you are working on support of .debug_rnglists, I am > > interested in the feature too, could you please po...

Hello Wolfgang and team, I see that you are working on support of .debug_rnglists, I am interested in the feature too, could you please point me out what else left to be done so that I could help you? -- Best Regards, Victor Leschuk | Software Engineer | Access Softek

...39;t think anyone has done a specific analysis to identify passes that lose debug info. However, various people/teams have an interest in making improvements here, and continue to devote some resources to the longer term project. For example there is the Extend Lifetimes work described by Wolfgang Pieb at the 2017 LLVM Developers Meeting. We have also looked into how the instruction scheduler might be interfering with the debugging experience. Part of the problem is that the "debugging experience" is a fairly qualitative thing, but in order to attack the problem properly we need a more...

Hello all, I've found an old post (November 2016) http://lists.llvm.org/pipermail/llvm-dev/2016-November/107006.html which discussed debug information for optimized code. At the end of that discussion, Adrian broached the interest in making -O1 only enable optimizations. I see in the code ( *clang/lib/Frontend/CompilerInvocation.cpp*, in function *getOptimizationLevel*) that *-Og* option is

...as done a specific analysis to identify passes that lose debug info. > > However, various people/teams have an interest in making improvements > here, and continue to devote some resources to the longer term project. > For example there is the Extend Lifetimes work described by Wolfgang Pieb > at the 2017 LLVM Developers Meeting. We have also looked into how the > instruction scheduler might be interfering with the debugging experience. > > Part of the problem is that the "debugging experience" is a fairly > qualitative thing, but in order to attack the proble...

...anyone has done a specific analysis to identify passes that lose debug info. > > However, various people/teams have an interest in making improvements here, and continue to devote some resources to the longer term project. For example there is the Extend Lifetimes work described by Wolfgang Pieb at the 2017 LLVM Developers Meeting. We have also looked into how the instruction scheduler might be interfering with the debugging experience. > > Part of the problem is that the "debugging experience" is a fairly qualitative thing, but in order to attack the problem properly we...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pieb, > Wolfgang via llvm-dev > Sent: Wednesday, July 05, 2017 6:14 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [DWARFv5] Reading the .debug_str_offsets section > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] O...

...specific analysis to identify passes that lose debug info. > > > > However, various people/teams have an interest in making improvements > here, and continue to devote some resources to the longer term project. > For example there is the Extend Lifetimes work described by Wolfgang Pieb > at the 2017 LLVM Developers Meeting. We have also looked into how the > instruction scheduler might be interfering with the debugging experience. > > > > Part of the problem is that the "debugging experience" is a fairly > qualitative thing, but in order to attack...

I have code along the lines of: void foo(struct A *a) { struct B *b = a->m_B; /* do a whole bunch of things with b */ } When LLVM generates code for this, it sees that after initializing b, a is no longer used, so it is optimized out. Unfortunately, for debug, I'd like the value for a to be kept around, if only so that I can determine the value of b and go from there. I

There was some discussion about this in D34765, and I had a follow-up chat with Wolfgang separately, plus spent a fair amount of time in reading and thinking today. I thought I would write my understanding all down here so we can reach a common understanding of how it ought to work, and therefore what our code should do. For any non-DWARF-experts who might be interested, in principle this

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