similar to: [DebugInfo] A value-tracking variable location update

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,

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more

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 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 Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, >

> 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 David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

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 Adrian, > quite a lot of work Large amounts of credit should go to llvm-reduce, which was fundamental to getting any of this done, > I've skimmed your implementation and it looks nice and well-documented. The thing that worries me is the over-complicated lattices -- I didn't anticipate the problem, and there's a risk that it's more complex than it needs to be. As it

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 here the failures. Anyway there is a suggested "revision" to use on PowerPC 32bit on Linux ? [...] llvm[0]: ***** Completed Release Build + make check llvm[0]: Running test suite make[1]: Entering directory `/home/llvm/work/src/llvm-2.8/test' Making a new site.exp file... Making LLVM 'lit.site.cfg' file... Making LLVM unittest

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

> I don't see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value). I think the distinction is still important; even at the IR level, if we

Hi all, I haven't seen a proposal for an optimised-code debugging experience Round Table yet so here goes! Please let me know if you are interested by emailing me at: orlando.hyams at sony.com Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end

Hi all, The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with

Hi, 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 on https://reviews.llvm.org/D45878, and since this is something that should be handled by all different

On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: > we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops > when compiling to bytecode without any optimizations. Apparently what > happens is that the loop header is duplicated, which results in two > entry points for the loop. this is actually a problem with the tailduplication pass of llvm. it does not consider

On Jun 11, 2008, at 6:27 AM, Florian Brandner wrote: > On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: >> we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops >> when compiling to bytecode without any optimizations. Apparently what >> happens is that the loop header is duplicated, which results in two >> entry points for the loop. > > this is

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable