<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 11, 2014 at 12:17 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> I think LLVM needs new IR to represent these semantics properly.</div>
</div></blockquote><div><br></div><div>Cool!  This proposal makes a lot of sense to me.</div><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 class=""><div class="h5"><span style="color:rgb(34,34,34)">> - Sections have linkage, all Values inside of a section must agree with the</span><br></div></div><div class="">
> section's linkage.<br>
<br>
</div>This seems way too restrictive and I don't think it maps to what<br>
object files actually do. We should be able to for example do<br>
<br>
$foo = section "bar", ..... comdat "zed", select_largest, etc<br>
<br>
@baz = private ... section $foo<br>
@bah = linkonce_odr alias baz, offset 4<br>
<br>
This fully general I think. In particular, the above example<br>
represents a section name bar, in a comdat represented by the symbol<br>
zed. The contents of the section is that of @baz and the only visible<br>
symbol in the section is bah, which is at offset 4.<br></blockquote><div><br></div><div>I like this proposal.  Any reason to use an explicit offset rather than allow GEPs into aliases?</div><div><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 class="">> The following is how I imagine MS RTTI would look like if we had this IR<br>
> construct:<br>
><br>
> $.vdata_for_type = pick_largest read<br>
> @my_rtti_for_type = pick_largest unnamed_addr constant %rtti_ptr_ty<br>
> @rtti_complete_object_locator, section $.vdata_for_type, align 4<br>
> @vftable_for_type = pick_largest unnamed_addr constant [1 x i8*] [i8*<br>
> bitcast (void (%struct.S*)* @"\01?fun@S@@UAEXXZ" to i8*)], section<br>
> $.vdata_for_type, align 4<br>
<br>
</div>Part of the problem is that it seems that the order is important. We<br>
really should not require that at the llvm IR level. The above global<br>
values could be output in any order.</blockquote><div><br></div><div>Yeah, let's not rely on order of the IR. </div><div><br></div><div>----</div><div><br></div><div><div>+The linkage must be one of ``appending``, ``linkonce_odr``, ``linkonce``.</div>
<div>+</div><div>+#. All values inside of a section must have ``external`` linkage if the section has</div><div>+   ``appending``.</div><div><br></div><div>It's kind of cute to use appending here, but why not just let 'external' mean the same as 'appending' for sections?  Then we can say something simple like "the linkage of all symbols in a section must be private, internal, or the linkage of the section."</div>
<div><br></div><div>+#. All values inside of a section must have ``linkonce_odr`` linkage if the</div><div>+   section has ``linkonce_odr``.</div><div>+</div><div>+#. All values inside of a section must have ``linkonce`` linkage if the</div>
<div>+   section has ``linkonce``.</div><div></div></div><div><br></div><div>Sounds like we're going to drop some of these restrictions.</div></div></div></div>