<div dir="ltr">(sorry for the duplicate Fred, I failed at reply-all the first time)<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 6:33 PM, Frédéric Riss <span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
> On Oct 22, 2014, at 4:57 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> Just working on some of the gmlt+fission debug info stuff and I came across a comment that might be relevant to reducing the number of distinct debugloc metadata nodes:<br>
><br>
> "or some sub-optimal metadata that<br>
>   // isn't structurally identical (see: file path/name info from clang, which<br>
>   // includes the directory of the cpp file being built, even when the file name<br>
>   // is absolute (such as an <> lookup header)))"<br>
><br>
> Seems that the file path/name isn't well canonicalized so as to allow metadata level merging when linking. Might be helpful to figure out that issue at some point.<br>
<br>
</div></div>Incidentally I worked on an issue last week where the line table would get entries representing the same file, but where the file/dir split wasn’t done at the same place. I have a patch that remerges them at emission, but I was planing on investigating more the source of the duplication before I submit anything.<br>
<br>
The cases I’ve seen have one duplicated entry though, nothing that could have a visible impact on memory consumption.<br></blockquote><div><br><div style="font-family:monospace">So the particular case where I think this arises in a way that might be measurable is if you have a build system that changes directories to build subprojects (like our make build system, if I understand correctly - but not our cmake build system, again, if I understand correctly):<br><br>imagine a simple directory layout:<br><br>  include/<br>    foo.h<br>  lib/<br>    a/<br>      a.cpp // includes foo.h and calls one inline function from it (or uses a type, etc) from some external function a()<br>    b/<br>      b.cpp // does the same thing as a.cpp, but with its own external function, b()<br><br>if you run "clang++ -emit-llvm -S -Iinclude -c lib/a/a.cpp lib/b/b.cpp -g" you get two .ll files both with the obvious:<br><pre style="white-space:pre-wrap;color:rgb(0,0,0)">!9 = metadata !{metadata !"include/foo.h", metadata !"/tmp/dbginfo/pathtest"}</pre></div><div style="font-family:monospace">But if you do this instead: "cd lib/a; clang++ -emit-llvm -S -I../../include -c a.cpp -g; cd ../../lib/b; clang++ -emit-llvm -S -I../../include -c b.cpp -g" you get two different nodes:<br><br><pre style="white-space:pre-wrap;color:rgb(0,0,0)">!9 = metadata !{metadata !"../../include/foo.h", metadata !"/tmp/dbginfo/pathtest/lib/b"}
<pre style="white-space:pre-wrap">!9 = metadata !{metadata !"../../include/foo.h", metadata !"/tmp/dbginfo/pathtest/lib/a"}</pre></pre>and now you're left with a situation in which almost all the metadata is different and any place you were relying on the standard metadata uniquing you won't get it :(</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Fred<br>
<div class=""><div class="h5"><br>
<br>
> - David<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</div></div></blockquote></div><br></div></div>