<div dir="ltr">Most of what I wanted to say has been said, but I wanted to explicitly call out COMDAT groups as something that we want that doesn't fit the atom model very well.<div><br></div><div>Adding first class COMDATs was necessary for implementing large parts of the Microsoft C++ ABI, but it also turns out that it's really handy on other platforms. We've made a number of changes to Clang's IRgen to do things like eliminate duplicate dynamic initialization for static data members of class templates and share code for complete, base, and deleting destructors.</div><div><br></div><div>Basically, COMDAT groups are a tool that the compiler can use to change the way things are linked without changing the linker. They allow the compiler to add new functionality and reduce coupling between the compiler and the linker. This is a real tradeoff worth thinking about.</div><div><br></div><div>I think for many platforms (Windows, Linux) Clang is not the system compiler and we need to support efficiently linking against existing libraries for a long time to come. There are other platforms (Mac, PS4) with a single toolchain where controlling the linker allows adding new functionality quickly.</div><div><br></div><div>I think Alex is right, we should probably meet some time and figure out what people need and how to support both kinds of platform well.</div><div><br></div><div>Reid</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 6:42 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><div>On May 1, 2015, at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div><blockquote type="cite"><b style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant:normal;letter-spacing:normal;line-height:20px;text-align:start;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px">The atom model is not the best model for some architectures
</b></blockquote><br></div></span><div>The atom model is a good fit for the llvm compiler model for all architectures.  There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom.  </div><div><br></div><div>The problem is the ELF/PECOFF file format.   (Actually mach-o is also section based, but we have refrained from adding complex section-centric features to it, so mapping it to atoms is not too hard).</div><div><br></div><div>I’d rather see our effort put to moving ahead to an llvm based object file format (aka “native” format) which bypasses the impedance mismatch of going through ELF/COFF.  </div><span class=""><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><b style="font-size:15px;line-height:20px;white-space:pre-wrap">One symbol resolution model doesn’t fit all</b><br></blockquote><br></div></span><div>Yes, the Resolver was meant to call out to the LinkingContext object to direct it on how to link.  Somehow that got morphed into “there should be a universal data model that when the Resolver process the input data, the right platform specific linking behavior falls out”.  </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>-Nick</div><div><br></div></font></span></div><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></blockquote></div><br></div></div></div></div>