search for: implicit_pointer

...> I’ve been reminded of PR37682, where a function with a reference > parameter might spend all its time computing the “referenced” value in a > temp, and only move the final value back to the referenced object at the > end. This is clearly a situation that could benefit from > DW_OP_implicit_pointer, and there is really no other-object DIE for it to > refer to. Given the current spec, the compiler would need to produce a > DW_TAG_dwarf_procedure for the parameter DIE to refer to. Appendix D > (Figure D.61) has an example of this construction, although it’s a more > contrived sour...

...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 variable). Before Dwarf is dumped in LLVM IR, we represent it using dbg.derefval (which denotes derefereced value of pointer or reference) and DW_OP_LLVM_implicit_pointer operation. 2. When a temporary variable is optimized...

...ity & 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 is what I think for each suggestion. DW_OP_LLVM_implicit_pointer * This is a good suggestion to include that in LLVM IR, because representation and specification (types of operands) of it a bit different that actual dwarf expression DW_OP_LLVM_implicit_pointer. while creating actual dwarf info it will be converted to DW_OP_LLVM_implicit_pointer. This is implem...

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 original patch should be splits for back-end changes + s...

...ingle level. (reference to reference is just reference > while pointer to pointer is double pointer). > Case of reference to reference, second level can be handled using > DW_OP_LLVM_explicit_pointer itself. > Case of pointer to reference, second level can be handled using > DW_OP_implicit_pointer. > > Though it would not be complex to make explicit pointer multilevel, I > avoided so due to lack of use case. Please let me know if I am missing > something. > Sorry, I couldn't understand your language related to references and pointers - I don't understand why they woul...

...om #0 source () at var.cpp:2 main () at var.cpp:10 10 sink(source()); Value returned is $1 = 3 (gdb) s sink (p=<optimized out>) at var.cpp:7 7 f(p); It'd be nice if the value of 'p' could be printed there, but it seems without introducing artificial variables, the implicit_pointer doesn't provide a way to do that & that seems to me like an unnecessary limitation & complication in the DWARF and in LLVM's intermediate representation compared to having 'p's DW_AT_location describe the value being pointed to directly without the need for another variable?...

...taining a pointer to actual_obj might be sub-optimal, > but after a “step in” to inline_me, the user wants to look at an expression > spelled *ptr even though the actual_obj might not have a memory address > (because fields are SROA’d into registers, or whatever). This is where > DW_OP_implicit_pointer saves the day; *ptr and ptr->x are still evaluatable > expressions, which expressions are secretly indirecting through the DIE for > actual_obj. > > > > I think it is not widely applicable outside of that kind of scenario. > Any ideas why it wouldn't be more general to...

...hin LLVM. To summarise the logic behind using this operator: LLVM debug info does not need to explicitly care about r-values or l-values before DWARF emission, only whether we're describing a variable's memory location, a variable's exact value, or some other implicit location (such as implicit_pointer). Whether an expression is an r-value or l-value can be trivially determined at the end of the pipeline (addMachineRegExpression already does this). For an expression ending with DW_OP_LLVM_direct: if the preceding expression is only a single register then we emit a register location, if the prece...

...was just for better readability in LLVM IR only later it (new intrinsic) was sharing the same path with llvm.dbg.value. So it should be fine to drop it without any impact in later functionality. >> - On question of identify such cases we can anyway identify using the type of expression (DW_OP_implicit_pointer). >> - On question of ( DW_OP_implicit_pointer ) fitting to dbg.value intrinsic it perfectly does that as value in such case is metadata and prototype of dbg.value is dbg.value(metadata, metadata, metadata). >> So it should be fine to drop it and back to where it was started before intr...

> 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