similar to: Defining the DIExpression operator DW_OP_LLVM_arg

Displaying 20 results from an estimated 400 matches similar to: "Defining the DIExpression operator DW_OP_LLVM_arg"

2020 Jul 08
3
Defining the DIExpression operator DW_OP_LLVM_arg
> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a DBG_VALUE to the stack, followed by a combination of DW_OP_dup, DW_OP_pick, DW_OP_swap, DW_OP_rot, and DW_OP_over. However, the resulting expressions can get very long and unwieldy and it is easier to generate efficient DWARF from
2020 Jul 08
2
Defining the DIExpression operator DW_OP_LLVM_arg
On Wed, Jul 8, 2020 at 9:29 AM Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > > On Jul 8, 2020, at 5:21 AM, Tozer, Stephen <stephen.tozer at sony.com> wrote: > > > >> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a
2020 Jul 08
2
Defining the DIExpression operator DW_OP_LLVM_arg
On Wed, Jul 8, 2020 at 9:48 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Jul 8, 2020, at 9:33 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 8, 2020 at 9:29 AM Adrian Prantl via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> > >> > >>> On Jul 8, 2020, at 5:21
2020 Feb 25
2
[RFC] Allowing debug intrinsics to reference multiple SSA Values
>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can
2020 Feb 21
4
[RFC] Allowing debug intrinsics to reference multiple SSA Values
What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically
2020 Aug 25
3
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
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
2019 Dec 18
4
DW_OP_implicit_pointer design/implementation in general
(I'm still pretty concerned that there are IR changes going in for a feature that seems incomplete and more invasive than really seems justified to me - though I admit I'm clearly not paying enough attention to this feature to have a nuanced/fully informed opinion & so maybe I just need to step back from all of this - but given the addition of new intrinsics, it seems like there should
2019 Nov 29
4
DW_OP_implicit_pointer design/implementation in general
Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another
2019 Nov 28
2
DW_OP_implicit_pointer design/implementation in general
Hi folks, I am pushing a PoC patch https://reviews.llvm.org/D70833 for review which includes the case when temporary is promoted. For such cases it generates IR as call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 And llvm-darfdump output looks like ------------- 0x0000007b:
2020 Sep 02
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we
2020 Feb 20
3
[RFC] Allowing debug intrinsics to reference multiple SSA Values
Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be
2020 Jan 14
2
DW_OP_implicit_pointer design/implementation in general
Hi, Let me consolidate what we discussed with my opinion. * On the point of new intrinsic llvm.dbg.derefval: It (new intrinsic) was more a neater way than a needed way. The whole functionality can go ahead without it and using llvm.dbg.value instead. Though I liked it (new intrinsic), since most of us are against it, it should be fine for me to drop it. This is because the transformation was
2020 Jan 01
2
DW_OP_implicit_pointer design/implementation in general
Hi David, Happy new year ! I just uploaded a POC patch that covers the cases when pointer points to un-named variables using DW_OP_implicit_pointer (references and dynamic allocation). This is using artificial variable as suggested by Paul. https://reviews.llvm.org/D72055 I hope that now it should address your concerns. Scope of DW_OP_implicit_pointer: As we initially decided split of
2019 Nov 20
2
DW_OP_implicit_pointer design/implementation in general
> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below
2020 Jan 13
2
DW_OP_implicit_pointer design/implementation in general
On Mon, Jan 13, 2020 at 9:20 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jan 10, 2020, at 11:36 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Fri, Jan 10, 2020 at 7:02 AM Jeremy Morse < > jeremy.morse.llvm at gmail.com> wrote: > >> Hi, > >> > >> On Wed, Jan 8, 2020 at 8:38 PM
2017 Feb 02
3
Tracking parts of expanded values in optimized debug
Hi all, I'm currently working on an out-of-tree backend and am trying to improve the debug experience when debugging optimized code. Our backend only has 8-bit and 16-bit legal types, so any larger values are expanded. The behavior I am currently seeing is that the expanded halves of an illegal type lose their debug information. Is this the expected behavior? For example, if I have an
2017 Sep 19
3
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.
2020 Mar 31
2
Question WRT llvm.dbg.value
> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > My understanding is that this isn't correct: dbg.declare specifies the >> memory address of a variable for the whole lifetime of the function, >> whereas dbg.value (and dbg.addr) specify the value/address until the >> next debug intrinsic. Mixing these two kinds
2020 Sep 09
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
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
2020 Apr 01
2
Question WRT llvm.dbg.value
> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that