search for: addr62

...the coroutine IR has guarantees about where > and when variables are loaded/stored from/to memory, it should be > possible to put more information into the IR, so that the rest of LLVM > doesn't have to guess. For example, this portion of IR: > > %15 = load i32, i32* %i.reload.addr62, align 4, !dbg !670 > call void @llvm.dbg.value(metadata i32 %15, metadata !659, metadata > !DIExpression()), !dbg !661 > %inc19 = add nsw i32 %15, 1, !dbg !670 > call void @llvm.dbg.value(metadata i32 %inc19, metadata !659, > metadata !DIExpression()), !dbg !661 > store i...

Hi all, I’m working on improving the debugging experience for C++20 coroutines when compiled with LLVM/Clang, and I could use some help from someone who understands debug information and DWARF (knowledge of coroutines isn't necessary, I don't think). Specifically, I’m trying to improve lldb’s behavior when showing variables in the current stack frame, when that frame corresponds to a

...pected the DWARF generated for the file. Unfortunately, inserting > dbg.addr that operated on the reloaded values didn't lead to any > change in the DWARF that was produced -- specifically, this didn't > make a difference: > > call void @llvm.dbg.addr(metadata i32* %i.reload.addr62, metadata > !873, metadata !DIExpression()), !dbg !884 Ouch, I tried this myself, and ran into the same difficulty. I'd missed that all your functions are marked "optnone" / -O0, which means a different instruction-selection pass (FastISel) runs, and it turns out FastISel isn'...

...Unfortunately, inserting >>> dbg.addr that operated on the reloaded values didn't lead to any >>> change in the DWARF that was produced -- specifically, this didn't >>> make a difference: >>> >>> call void @llvm.dbg.addr(metadata i32* %i.reload.addr62, metadata >>> !873, metadata !DIExpression()), !dbg !884 >> >> Ouch, I tried this myself, and ran into the same difficulty. I'd >> missed that all your functions are marked "optnone" / -O0, which means >> a different instruction-selection pass (FastIS...

...d for the file. Unfortunately, inserting > > dbg.addr that operated on the reloaded values didn't lead to any > > change in the DWARF that was produced -- specifically, this didn't > > make a difference: > > > > call void @llvm.dbg.addr(metadata i32* %i.reload.addr62, metadata > > !873, metadata !DIExpression()), !dbg !884 > > > > > > Ouch, I tried this myself, and ran into the same difficulty. I'd > > missed that all your functions are marked "optnone" / -O0, which means > > a different instruction-selection pa...