<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 12/14/2015 12:46 PM, JF Bastien
wrote:<br>
</div>
<blockquote
cite="mid:CABdywOcPBh+bQhFJnYC+KJmZdGKj8qt7nA5Eytn4njb_5Z4Vgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Dec 14, 2015 at 11:46 AM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.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 text="#000000" bgcolor="#FFFFFF">
<div>
<div class="h5"> <br>
<br>
<div>On 12/12/2015 01:44 PM, JF Bastien wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Dec 12, 2015
at 1:24 AM, Philip Reames <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></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">Patch
posted for review: <a
moz-do-not-send="true"
href="http://reviews.llvm.org/D15471"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://reviews.llvm.org/D15471">http://reviews.llvm.org/D15471</a></a></blockquote>
<div><br>
</div>
<div>Looking at the patch, I think we should
do FP only for now as vectors have extra
complexities which IMO warrant more
discussion. <br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
I'm fine with splitting the patch up to make progress.
I'll post a split patch shortly. <br>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks. FWIW I think we'll want to do vectors, but I
think it's trickier than just FP.</div>
</div>
</div>
</div>
</blockquote>
Agreed. :)<br>
<blockquote
cite="mid:CABdywOcPBh+bQhFJnYC+KJmZdGKj8qt7nA5Eytn4njb_5Z4Vgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">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>
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>
<br>
<blockquote
cite="mid:CABdywOcPBh+bQhFJnYC+KJmZdGKj8qt7nA5Eytn4njb_5Z4Vgg@mail.gmail.com"
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>
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>
<blockquote
cite="mid:CABdywOcPBh+bQhFJnYC+KJmZdGKj8qt7nA5Eytn4njb_5Z4Vgg@mail.gmail.com"
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>
Well, the former isn't legal. It isn't a power of two size. I'm
not suggesting we relax that requirement. <br>
<br>
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>
<br>
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>
<br>
<blockquote
cite="mid:CABdywOcPBh+bQhFJnYC+KJmZdGKj8qt7nA5Eytn4njb_5Z4Vgg@mail.gmail.com"
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>
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>
<br>
Philip<br>
<br>
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>
<br>
<br>
</body>
</html>