<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 7, 2014 at 6:20 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.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"><div class="gmail_extra"><div class="gmail_quote"><div class="">On 6 May 2014 11:24, 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">ping</div></blockquote><div><br></div></div><div class="gmail_quote">+ If the third field is present, non-null, and points to a global variable</div><div class="gmail_quote">+ or function, the initializer function will only run if the associated</div>


<div class="gmail_quote">+ data from the current module is included in the final linked image.</div><div class="gmail_quote"><br></div><div class="gmail_quote">"included in the final linked image" isn't well-defined at the level of LLVM IR. I think you mean "is not discarded", but I'm not certain.</div>
</div></div></div></blockquote><div><br></div><div>"is not discarded" seems correct.  The only subtlety is that its just the data from the current module.  If the some other module has a definition for the same global value and our global is discarded and the other definition is kept, this initializer is discarded and no initializer is run.  This lets us aggressively eliminate these initializers in globalopt.  =D</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">-      Assert1(STy && STy->getNumElements() == 2 &&<br>
+      Assert1(STy && (STy->getNumElements() == 2 ||<br>+                      STy->getNumElements() == 3) &&</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">So you're going to permit old-style and new-style in the IR. What happens when I link the two? I think you need to autoupgrade to the new 3-argument form.</div>
</div></div></blockquote><div><br></div><div>Right.  I taught us to auto-upgrade this and added a linker test.  Do we want to force all frontends to switch to the new IR style up front?  I'm hesitant to do it because it would break a frontend using the C API to emit initializers.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">+ namespace {<br>
</div><div class="gmail_quote"><div class="gmail_quote">+ struct Structor {</div><div class="gmail_quote">+   Structor() : Priority(0), Func(0), ComdatKey(0) {}</div>

<div class="gmail_quote">+   int Priority;</div><div class="gmail_quote">+   llvm::Constant *Func;</div><div class="gmail_quote">+   llvm::GlobalValue *ComdatKey;</div><div class="gmail_quote">+ };</div><div class="gmail_quote">


+ } // end namespace</div><div><br></div></div><div class="gmail_quote">C++11-ification: nullptr instead of 0, in-class initializers instead of a constructor.</div></div></div></div></blockquote><div><br></div><div>I think I actually drafted this before the C++11 switch, and never sent it out.  :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">

I'd appreciate if someone else reviewed the MC changes.</div></div></div></div></blockquote><div><br></div><div>I'm actually pretty confident about that side of it.  It's pretty simple: generate COFF with these bits, please.</div>
</div></div></div>