<div dir="ltr">First, I'd like to say it would be great if we could get away from relying on these globally unique pass IDs represented as addresses of globals. Long ago I tried to hack up a DLL build of LLVM and quickly discovered that these IDs are the biggest source of dllimported data, which has to be annotated with __declspec(dllimport/dllexport).<div><br></div><div>Here's the issue as I understand it:</div><div>- LLVM today supports using mingw64 compilers with -DBUILD_SHARED_LIBS=ON. This produces a DLL per LLVM library, just like Unix.</div><div>- In lib/Analysis, each analysis inherits from a CRTP base class AnalysisBase.</div><div>- AnalysisBase is very simple, it exists solely to provide the unique pass ID in the form of a static data member.</div><div>- Because the ID is part of a template, it is only emitted when referenced. This is the same on Windows and Unix, no compiler bug here.</div><div>  - Previously, each analysis would manually provide it's own ID, and the ID would be emitted exactly once in the TU providing the analysis.</div><div>- The Windows loader is very simple, it does not merge symbols across DSOs as it does on Unix. As a result, the IDs are not unique, leading to runtime problems.</div><div>  - The auto-dll tools provided by mingw might not let you get this far, though, I haven't actually seen the logs.</div><div><br></div><div>You introduced AnalysisBase to eliminate the boilerplate of declaring and defining the ID of each analysis, and discovered that it just means we have to put back a different kind of boilerplate in the form of explicit template instantiations.<br></div><div><br></div><div>I don't think we can overcome the boilerplate here, if we want to support BUILD_SHARED_LIBS on Windows, regardless of compiler. It's a limitation of DLLs, and a useful one because it avoids doing tons of useless symbol lookup at startup.</div><div><br></div><div>So, the options are:</div><div>1. Go back to declaring IDs in each analysis. It's tried and true and doesn't have vague linkage like templates.</div><div>2. Push forward with extern template declarations, which is a new kind of boilerplate that most users of LLVM probably don't understand very well.</div><div>3. Drop support for BUILD_SHARED_LIBS. This might not actually be viable if we want to try to support transforms and analysis provided by loadable plugins. I'm not sure what issues would arise here.</div><div><br></div><div>I guess I favor 1.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 9:01 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Folks, there is an issue pretty buried in the commits list that I suspect should have wider visibility.<div><br></div><div>See r262188 and subsequent discussion. To summarize: it appears that mingw32 was unable to correctly produce a static data member when instantiated as a base class. The "fix" is to then explicitly instantiate the base class separately from its use in a base class.</div><div><br></div><div>I think this is unacceptable in this case because these base classes are intended to be the primary way that users of LLVM will define new analysis passes. That means we'll actually have to teach LLVM library users about this pattern, not just the LLVM developers. =/</div><div><br></div><div>So my questions are:</div><div><br></div><div>1) Is there some more elegant way to fix this that doesn't require every derived class to write an explicit instantiation definition of their base class? If so, then the rest of my questions are moot.</div><div><br></div><div>2) If not, is this a problem with a native Windows 32-bit DLL build?</div><div><br></div><div>3) If this is a problem with the native Windows 32-bit DLL build, should we back out of using this pattern of CRTP injection of the static data member and just deal with the significant (and error prone) boiler plate? It seems less error prone than the alternative.</div><div><br></div><div>4) If this is not a problem with the native Windows 32-bit DLL, then I wonder how valuable it is to continue to support the conjunction of mingw32 and a DLL build? This seems to be a really high cost to carry.</div></div>
</blockquote></div><br></div>