<div dir="ltr">Should we rename it to match the renamed actual function name? So there's some chance the debugger can identify each one separately, even if the user never wrote it that way?<br><br>I'm not really sure what a good debugging experience is going to look like if a function is cloned, but I do know (from the other thread about DWP/DWO/Fission/LTO) that having two subprograms with the same name in the same scope doesn't do good things in GDB - not sure if it could be made to do so either... </div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 3, 2017 at 4:58 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just wrote an IR Verifier check that catches the following situation:<br>
<br>
  ; RUN: not llvm-as %s -disable-output 2>&1 | FileCheck %s<br>
<br>
  define void @f1() !dbg !4 {<br>
    unreachable<br>
  }<br>
<br>
  ; CHECK:      DISubprogram attached to more than one function<br>
  define void @f2() !dbg !4 {<br>
    unreachable<br>
  }<br>
<br>
  !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!1}<br>
  !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2)<br>
  !2 = !DIFile(filename: "t.c", directory: "/path/to/dir")<br>
  !3 = !{}<br>
  !4 = distinct !DISubprogram(name: "foo", scope: !1, file: !2, unit: !1)<br>
<br>
<br>
Why? When two functions share the same DISubprogram attachment, the DWARF backend gets very confused and adds all attributes from all functions to the same subprogram DIE, so we end up with something looking like:<br>
<br>
  DW_TAG_subprogram<br>
     DW_AT_low_pc // f1<br>
     DW_AT_high_pc<br>
     DW_AT_low_pc // f2<br>
     DW_AT_high_pc<br>
     ... etc.<br>
<br>
Seeing this it seemed obvious to me we should disallow this by preventing two functions from sharing the same !dbg attachment. After implementing my new verifier check (and updating a couple of hand-crafted testcases that violated it) I noticed that the new check causes the cloning unit test to fail:<br>
<br>
When CloneFunction clones a function into the same module, it will not create a deep copy of the function's debug info. Before I start fixing this (which is a bit of work, because we will need to re-parent all of the function's DILocations into the cloned DISubprogram) I wanted to get everyone's opinion on whether this is the right approach.<br>
<br>
tl;dr: Basically, when invoking CloneFunctionInto on:<br>
<br>
  define void @f() !dbg !3 {<br>
    ret void, !dbg !4<br>
  }<br>
<br>
  define void @f_clone()<br>
<br>
  !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!1}<br>
  !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2)<br>
  !2 = !DIFile(filename: "t.c", directory: "/path/to/dir")<br>
  !3 = distinct !DISubprogram(name: "foo", scope: !1, file: !2, unit: !1)<br>
  !4 = !DILocation(line: 1, scope: !3)<br>
<br>
I would like the result to be:<br>
<br>
  define void @f() !dbg !3 {<br>
    ret void, !dbg !4<br>
  }<br>
<br>
  define void @f_clone() !dbg !5 {<br>
    ret void, !dbg !6<br>
  }<br>
  !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!1}<br>
  !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2)<br>
  !2 = !DIFile(filename: "t.c", directory: "/path/to/dir")<br>
  !3 = distinct !DISubprogram(name: "foo", scope: !1, file: !2, unit: !1)<br>
  !4 = !DILocation(line: 1, scope: !3)<br>
  !5 = distinct !DISubprogram(name: "foo", scope: !1, file: !2, unit: !1)<br>
  !6 = !DILocation(line: 1, scope: !5)<br>
<br>
Thoughts?<br>
<br>
-- adrian<br>
</blockquote></div>