[llvm-bugs] [Bug 49270] New: MemCpyOptimizer should take the merged debug location

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49270

            Bug ID: 49270
           Summary: MemCpyOptimizer should take the merged debug location
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: yuanboli233 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 24554
  --> https://bugs.llvm.org/attachment.cgi?id=24554&action=edit
old_debug.ll

Overview, the memcpyopt pass preserves the debug location of one instruction
when merging two stores, however, according to the LLVM debug info update
guide, the debug location should be merged and then applied.

Steps to reproduce:
$ clang++ --version
clang version 13.0.0 (https://github.com/llvm/llvm-project.git
0b5d8d668c210f263a93821fd51c564313c96099)
Target: x86_64-unknown-linux-gnu
Thread model: posix

The IR file "old_debug.ll" is uploaded as an attachment.

$ opt -memcpyopt old_debug.ll -S > new.ll

In the original old_debug.ll file, the instruction "store i32 0, i32*
%arrayidx, align 4, !dbg !14" and "tail call void @llvm.memset.p0i8.i64(i8* %0,
i8 0, i64 11, i1 false), !dbg !17" are merged into one llvm.memset intrinsic in
the optimized file "new.ll". However the debug location "!dbg !17" of the
llvm.memset in the optimized file is actually the debug location of the
llvm.memset in the original IR file. According to my understanding of LLVM
debug info update guide:
https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-merge-instruction-locations,
when the pass tries to merge multiple block-local instructions into one, it
should apply the merged debug location instead of preserving one of the debug
locations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210219/3bcda931/attachment.html>