similar to: gberry@codeaurora.org

> On May 7, 2018, at 11:29 PM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, (Resent with proper subject line) > > I recently found myself in trouble because the crash I had disappeared > with -g, so I could not debug the program. This happened because the > optimizer did not remember to consider DBG_VALUEs

Hi, (Resent with proper subject line) I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this onhttps://reviews.llvm.org/D45878, and

Hi Jonas, Thanks for starting the discussion here. I am going to update the subject line some people might overlook it otherwise. I have a few thoughts which I have highlighted below. > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jonas Paulsson > via llvm-dev > Sent: Friday, May 4, 2018 2:57 AM > > Hi, > > I

Awesome to read how it's coming along - I'm mostly aside from the debug location work, but had just one or two clarifying questions On Fri, Nov 6, 2020 at 10:27 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi debug-info folks, > > Time for another update on the variable location "instruction referencing" > implementation I've been doing,

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors

Hi debug-info folks, Time for another update on the variable location "instruction referencing" implementation I've been doing, see this RFC [0, 1] for background. It's now at the point where I'd call it "done" (as far as software ever is), and so it's a good time to look at what results it produces. And here are the scores-on-the-doors using llvm-locstats, on

The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! thanks, Adrian > On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > In retrospect I totally agree with you. I am looking at LiveDebugValue again to see

Hi Quentin, Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /Patrik Hägglund [MachineSinking] Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse register

Hi Vedant, thanks for the detailed response, On Tue, Feb 25, 2020 at 7:23 AM Vedant Kumar <vedant_kumar at apple.com> wrote: > > Finally, being forced to always specify both the machine location and > > the program location at the same time (in a single DBG_VALUE) > > introduces un-necessary burdens. In MachineSink, when we sink between > > blocks an instruction that

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the

> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Good point. > > Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x" > > My fix would be to propagate the DEBUG_VALUE only if "x" is associated with only a

Hi Jonas, Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. Thanks, Sejong From: jdevlieghere at apple.com <jdevlieghere at apple.com> Sent: Wednesday, March 14, 2018 4:07 AM To: Se

Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with constant. Sejong From: aprantl at apple.com <aprantl at apple.com> Sent: Monday, April 30, 2018 1:53 PM To: Se Jong Oh <sejooh at microsoft.com> Cc: jdevlieghere at apple.com; Vedant Kumar <vsk at apple.com>; llvm-dev at lists.llvm.org; pidgeot18 at gmail.com Subject: Re: [llvm-dev] [SelectionDAG]

Hi Jonas, I have another case that DBG_VALUE is not produced. I would appreciate it if you could take a quick look at the testcase below. test code: llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll ; Function Attrs: nounwind ssp uwtable define void @f() #0 !dbg !4 { entry: tail call void @h(i16 0) #2, !dbg !14 %call = tail call i16 (...) @g() #2, !dbg !15 tail call void

> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do

> On Apr 30, 2018, at 1:49 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > I have another case that DBG_VALUE is not produced. I would appreciate it if you could take a quick look at the testcase below. > > > test code: > > llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll > > ; Function Attrs: nounwind ssp uwtable >

Hi, I work with an out-of-tree backend for a VLIW architecture and we use bundling extensively. We have opted to put DBG_VALUES inside bundles to keep them together with their originating instructions. However, as no (in-tree) backends do this to our knowledge, we have recently started to question if that's a wise approach. Several patches are needed to make bundled DBG_VALUEs work and since

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. For an example we can look no further than the actual test which has been disabled after the fix