<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 14, 2014 at 11:17 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Wed, May 14, 2014 at 11:01 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>On Wed, May 14, 2014 at 10:12 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, May 14, 2014 at 8:58 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br>
</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"><div>I'm a bit concerned with moving the DLLImport/DLLExport related linkage calculation into Sema out of CodeGen. I have a feeling that this will trigger warn_static_local_in_extern_inline when a static local variable inside of a dllimport'd function.<br>
<br>
Considering that other things like VTables and RTTI don't rely on the GVALinakge mechanism and will need the ability to "upgrade" some linkage to a DLLImport/DLLExport friendly linkage, I think I'd rather see a DLLImport/DLLExport handled via a function which takes an arbitrary llvm::GlobalVariable linkage and a Decl and figures out what the final linkage should be.<br>
<br></div>
This kind of upgrading is common inside of CodeGen, GetAddrOfGlobalTemporary is a notable example of this.]<br></blockquote><div><br></div><div>IMO the linkage at the AST level should reflect what the user wrote, and the user used dllexport plus inline, giving GVA_StrongODR. This is useful information for other Clang-based tools.</div>
</div></div></div></blockquote><div><br></div></div><div>I'd agree with this if we modeled stuff like fapple-kext in there but we don't. There are things that we simply can't model like WeakAttr, we don't know if we will end up with WeakODR or WeakAny until we try to evaluate the initializer.</div>
</div></div></div></blockquote><div><br></div></div><div>I'll have to read up on WeakAttr tomorrow.</div><div class=""><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">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><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">
<div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>I think CodeGen will always have to munge GlobalValue linkages for entities that don't exist in the user's program, for example, vtables and global reference temporaries.</div></div>
</div>
</div></blockquote></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">This route will require us to duplicate handling of dllexport/dllimport in both AST and CodeGen, I'd rather it just see it live in CodeGen.</div>
</div></blockquote><div><br></div></div><div>True, we'll need both, but we already have this kind of code for entities that aren't part of the AST, like vtables.</div><div class=""><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">
<div dir="ltr"><div class="gmail_extra">I'd be happier with this if we can move stuff like -fapple-kext into GVALinkage and we add more tests for static variables inside dllimport/dllexport'd functions.<br>
</div></div>
</blockquote></div></div><br></div><div class="gmail_extra">I view -fapple-kext as less of an AST-level, "what the user wrote" thing and more of a codegen option that hacks the ABI to maintain backwards compatibility with one of the Ancient Ones.</div>
</div>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't think it's particularly useful for high-level examination of linkage, it can flat out lie sometimes. In the following case, GVALinkageForVariable will claim that the VarDecl has GVA_DiscardableODR when it in-fact will be emitted as "external global"</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">template <typename T></div><div class="gmail_extra">struct S {</div><div class="gmail_extra"> static int i;</div><div class="gmail_extra">
};</div><div class="gmail_extra"><br></div><div class="gmail_extra">int *f() { return &S<void>::i; }</div><div class="gmail_extra"><br></div><div class="gmail_extra">We should either commit to GVA as meaningful and GetGVALinkageFor* as useful or we should consider them utility functions utilized by Sema/CodeGen.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I tend to view them as the latter.</div></div></div>