search for: aloksharma

...arly 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 be more clear design discussion) On Tue, Dec 10, 2019 at 9:06 PM Alok Sharma <aloksharma.knit at gmail.com> wrote: > Hi David, > > This is regarding missing multilevel handling in branch for explicit > pointers. > > > * does the proposed IR format support multiple layers of dereference > (eg: int ** where we know it ultimately points to the value 3 but can...

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

...someone finds that the value on top of this, of knowing > the name of the variable being pointed to, is worth the added complexity - > then we could do that. But my gut feel is that it is not worth the added > complexity. > > > > On Mon, Dec 23, 2019 at 11:05 PM Alok Sharma <aloksharma.knit at gmail.com> > wrote: > >> > Hmm. I don't understand why references would be handled differently >> than pointers. Could you explain further? References and pointers can point >> to unnamed entities (things without a variable DIE), so if that's the >&g...

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

...review here, I think? Once the general direction seems good, we can go into the separate review threads for the implementation/mechanical details. On Tue, Jan 14, 2020 at 8:47 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jan 13, 2020 at 8:49 PM Alok Sharma <aloksharma.knit at gmail.com> wrote: >> >> 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 w...