In this code variables l_271 and l_253 are not available at -O2/-O3 during debugging at line 9.
In short, GVN introduces a PHI node for the value of b needed in the expression at line 9. As incoming values, for the if part GVN creates a BB to host a load i8 from variable b, while for the else part it forwards the value just read from d. In the debug metadata, this PHI node is assigned with line number 9. Therefore, since for l_271 and l_253 the associated llvm.dbg.value() operations come after the PHI node, the variables become visible only after line 9 has executed (i.e., only on line 10 when the function returns).
How may debug information be preserved here? For instance, could it be possible for the llvm.dbg.value() to be similarly duplicated and moved?
We tested clang and lldb 14.0.0 commit 116dc70 on x64. We identified GVN using opt-bisect-limit, please find attached the full IR before and after it. For a quick read we inline instead an excerpt after GVN.
In this code variables
l_271
andl_253
are not available at -O2/-O3 during debugging at line 9.In short, GVN introduces a PHI node for the value of
b
needed in the expression at line 9. As incoming values, for the if part GVN creates a BB to host aload i8
from variable b, while for the else part it forwards the value just read fromd
. In the debug metadata, this PHI node is assigned with line number 9. Therefore, since forl_271
andl_253
the associatedllvm.dbg.value()
operations come after the PHI node, the variables become visible only after line 9 has executed (i.e., only on line 10 when the function returns).How may debug information be preserved here? For instance, could it be possible for the llvm.dbg.value() to be similarly duplicated and moved?
We tested clang and lldb 14.0.0 commit 116dc70 on x64. We identified GVN using
opt-bisect-limit
, please find attached the full IR before and after it. For a quick read we inline instead an excerpt after GVN.before-GVN.ll.txt after-GVN.ll.txt
LLDB trace:
Excerpt of the IR after GVN: