<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Tue, Jun 19, 2012 at 11:12 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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">Moving to cfe-dev to catch the attention of people who know something about this...<div>
<br><div><div class="im"><div>On Jun 19, 2012, at 10:55 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div><br><blockquote type="cite"><div style="font-family:arial,helvetica,sans-serif">
<font size="2"><div class="gmail_quote">On Tue, Jun 19, 2012 at 8:42 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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">Author: atrick<br>
Date: Tue Jun 19 22:42:09 2012<br>
New Revision: 158787<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=158787&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=158787&view=rev</a><br>
Log:<br>
Move the implementation of LoopInfo into LoopInfoImpl.h.<br>
<br>
The implementation only needs inclusion from LoopInfo.cpp and<br>
MachineLoopInfo.cpp. Clients of the interface should only include the<br>
interface. This makes the interface readable and speeds up rebuilds<br>
after modifying the implementation.<br></blockquote><div><br></div><div>Technically speaking, I think you need to declare the templates as 'extern' for this to be valid (<a href="http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=549" target="_blank">http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=549</a> is the best link I have).</div>

<div><br></div><div>This is a C++11 feature, but it is available with GCC since ~forever as an extension. It often "just works" without it, but my understanding is that technically it isn't valid as any old TU that uses these constructs is supposed to have a definition available.</div>

<div><br></div><div>At least for compilers that support it putting the various things like:</div><div><br></div><div>__extension__ extern template class LoopInfoBase<BasicBlock, Loop>;</div><div><br></div><div>Into the header would make me happier...</div>

<div><br></div><div>I'm OK relying on compilers to make this "just work" if they don't support the extension (MSVC likely, dunno), but where the do, this will make sure everything works together nicely.</div>
</div></font></div></blockquote><div><br></div></div><div>I thought the "extern template" was purely an optimization and unlikely to have any benefit with clang in this limited setting. But I'm glad you pointed it out, because I was hoping someone could explain the situation to me.</div>
<div><br></div><div>My basis for making the change to explicit instantiation is that we've been using the pattern for a year now elsewhere in LLVM and no one has complained.  I didn't mess with "extern template" because I didn't want to introduce something confusing and compiler-specific without a good reason.</div>
</div></div></div></blockquote><div><br></div><div>AFAICT, we've been lucky... The standard isn't (IMO) terribly clear here, but the only reading of it I'm comfortable with is that calling a member function of a class template requires that member function's definition to exist, which requires instantiating it. If there *is* no definition, we've got an invalid program.</div>
<div><br></div><div>Now, I'm not aware of any compilers that really care about this in the cases you're dealing with -- they're usually able to call the function just fine without instantiating it and so they carry on without a diagnostic, and as long as we link in a definition eventually, everything "Just Works". But I'm much more confident if we use one of the standard (C++11) or extension (everything else) specified ways of achieving this result.</div>
<div><br></div><div>There are also some benefits to using it. If we leave any methods defined inline (perhaps for performance reasons), we can avoid emitting them into the '.o' file everywhere they are used but not inlined. There are a few other similar edge cases where this actually helps.</div>
</div></font></div>