<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@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 class="">> Looking a little deeper, it's not "old-style" exactly; rejecting this<br>
> isn't trivial.<br>
><br>
>   - According to LangRef, the third field is optional [1].<br>
><br>
> [1]: <a href="http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable" target="_blank">http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable</a><br>
><br>
>   - It was added in r209015 to support comdat keys.<br>
><br>
>   - The helper functions `llvm::appendToGlobalCtors()` and<br>
>     `llvm::appendToGlobalDtors()` (in ModuleUtils.cpp) will by default<br>
>     set up the two-field version.<br>
><br>
>   - Despite the field being optional (and the API defaulting to the<br>
>     short version), the BitcodeReader auto-upgrades to the 3-element<br>
>     version.<br>
><br>
> It looks to me like `@llvm.global_ctors` and `@llvm.global_dtors` are in<br>
> an inconsistent state here.  In particular, with the same version of the<br>
> tool, if you generate the arrays you get one type, then if you write to<br>
> bitcode and read it back you get another type.<br>
><br>
> There are a few ways to move forward:<br>
><br>
>  1. Remove the auto-upgrade from the BitcodeReader, making the third<br>
>     field truly optional.  Why create them one way, and round-trip to<br>
>     bitcode another way?<br>
><br>
>  2. Make the third field *required*.  This primarily means:<br>
><br>
>     - changing `appendToGlobal?tors()` (etc.?) to add the third field<br>
>       immediately instead of waiting for a bitcode rount-trip and<br>
>     - rejecting the two-field version in .ll.<br>
><br>
>     This is another way of removing the inconsistency.<br>
><br>
<br>
</div>I have a small preference for 2, but just because it makes the current<br>
IR definition simpler. Reid implemented the auto upgrade, so he<br>
probably has a better insight on which option is best.<br></blockquote><div><br></div><div>Nick was in favor of 2 as well, which is what pushed me to do the auto-upgrade, even though I initially intended for this to be optional.  I didn't want to force the complexity of the 3 operand form on non-C++ frontends, basically.  Obviously, having one form is simpler from LLVM's perspective.</div>
</div></div></div>