<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Mar 1, 2016 at 4:21 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>I don't disagree with your analysis, but I'd like to get a build bot that tests DLL builds with a host toolchain other than mingw32 if this is in fact common to those configs (as no other bot broke that i saw)... But that's a separate issue.</div><div><br></div><div>The base class isn't *just* providing the static variable. It is also providing the accessor method. I really like using a method instead of raw access to the static data member. It is also providing the name of the pass. So what we'd likely end up with is still having the base class but having a friend declaration and private static data member in the derived class.</div><div><br></div><div>But before going there, I'd like to ask if there is another approach that would work: do you see any ways to effectively cause the static data member to be emitted reliably?</div></div></div>