<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 text="#000000" bgcolor="#FFFFFF"><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 text="#000000" bgcolor="#FFFFFF">Would you mind
explaining what complexities you see for vectors? As
per my direct email, the set of vectors which can
practically be made atomic may be smaller than we'd
like, but the existing atomic semantics seem to map
cleanly. What am I missing?</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I'm also concerned about:</div>
<div class="gmail_extra">
<ul>
<li>Alignment is the big one, I think we'll want to discuss
having entirely atomic vectors as well as vectors whose
elements are atomic only.<br>
</li>
</ul>
</div>
</div>
</blockquote></span>
Not sure how the second part relates to the first part. I agree
that we probably want a notion of element-wise atomicity for vector
(and possibly struct/array) types, but I think that should come
later. Specifically, I think we'd need an alternate spelling for an
element-wise for on atomic, so I see no harm in having the support
for fully atomic vectors added now. <br><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<ul>
<li>Having vectors of pointers without fully supporting
atomic pointer.<br>
</li>
</ul>
</div>
</div>
</blockquote></span>
We support atomic pointer operations in loads and stores. Again,
what we support in load/store is currently separate from what we
support in atomicrmw/cmpxchg. We should unify the later with the
former, but that's a separate issue. <br></div></blockquote><div><br></div><div>Ha, I didn't realize we did, I though it had to go through intptr casts just like FP does but r162146 added it back in 2012. The documentation and verifier look slightly wrong, <a href="http://reviews.llvm.org/D15512">here's a proposed fix</a>.</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 text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<ul>
<li>Vectors of unusual sizes or integer types being atomic,
and how they get legalized. e.g. <3 x i32> or
<256 x i1>.</li>
</ul>
</div>
</div>
</blockquote></span>
Well, the former isn't legal. It isn't a power of two size. I'm
not suggesting we relax that requirement. <br></div></blockquote><div><br></div><div>Indeed, I'd like to make sure we don't and have some pretty explicit testing for it.</div><div><br></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 text="#000000" bgcolor="#FFFFFF">If it has a power of two store size, then it should get the
equivalent handling to an iX of the same size. I don't see the
issue here. How is the second example any different from an atomic
i256?<br></div></blockquote><div><br></div><div>i1 isn't storable as-is :-)</div><div><br></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 text="#000000" bgcolor="#FFFFFF">
Actually, this brings up a related issue. We seem to have no
documentation in the lang ref about how vector types are represented
in memory. The actual implementation appears to assumed packed
bits, but the docs don't say. Depending on what the semantics here
are, my assumptions in the last two paragraphs may not be valid. <br></div></blockquote><div><br></div><div>Indeed!</div><div><br></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 text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<ul>
<li>Once we add vector, should we consider adding other
composite types in general, including structs? C++ allows
this, but has substantial issues w.r.t. padding.</li>
</ul>
</div>
</div>
</blockquote></span>
I'd say possibly, but FCAs are poorly supported in the IR in
general. I am not willing to block changes for vectors on changes
for FCAs. This has never been our policy in the past and should not
become so now. <br></div></blockquote><div><br></div><div>Oh yeah I don't think we should block it. FWIW I expect that some of these will generate calls to the runtime's global atomic lock shard, which is horrible.</div><div><br></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 text="#000000" bgcolor="#FFFFFF">
p.s. Thanks for asking clarifying questions. Getting this all
hammered out is definitely a good idea. I just want to make sure we
close the loop quickly so that this doesn't get stalled. <br></div></blockquote><div><br></div><div>You mean, more stalled that the holidays will already stall it? ;-) </div></div><br></div></div>