- User Since
- May 27 2020, 5:51 PM (10 w, 3 d)
Jun 2 2020
@Orlando I think you are probably right. It should indeed prints $0=1. I appreciate your patience and my apology for the report. Shall I close the original PR?
Jun 1 2020
Thanks @Orlando, I think I agree with your reasoning. My patch on introducing an undef is based on the same reasoning (but I could be totally wrong).
May 31 2020
I have added the test case and made a minor change. The RemoveRedundantDbgInstrs call will always keep the second dbg.value. If we do RAUW first, the corresponding value will be replaced -- that causes PR46114. With this patch, we set it as undef. If I missed anything, please let me know. I think @Orlando's suggestion on merging the locations will be a good improvement.
May 29 2020
May 28 2020
Re-formatted the comment.
During EarlyCSE we detect that %0 = load i32, i32* @a is the same as
%1 = load i32, i32* @a, so the latter is removed. We rewrite the dbg.value
which uses %1 to use %0 instead, because %1 is being removed. IIUC this
behaviour in EarlyCSE looks correct, and makes me feel like the issue
comes from somewhere else?
call void @llvm.dbg.value(metadata i32 0, metadata !22, metadata !DIExpression()), !dbg !31 call void @llvm.dbg.value(metadata i32 %0, metadata !22, metadata !DIExpression()), !dbg !31
and lldb can print the correct value of 0.