search for: dbg_value_list

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely instead, and so I'm looking for any comments on this change before pushing ahead with it. There are a few differences between the MIR...

...s of the parameters being available in the function or as entry values. I have not yet delved into the discussion about the multi-location debug values, so I don't have any proposals for how that could look. I guess it can (somehow) be mapped into that. It is clear to me that the usage of the DBG_VALUE_LIST will be appropriate for the "Salvage Debug Info", but the idea of using the entry values on IR level is more general (not very localized), and there is the cause of potential complexity, since we need to carry that info throughout IR and use it as a backup. Best regards, Djordje ________...

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

...zer, Stephen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely instead, and so I'm looking for any comments on this change before pushing ahead with it. Thank you for writing this up! I think this...

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