<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 04:23 PM, JF Bastien
wrote:<br>
</div>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@mail.gmail.com"
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"><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 moz-do-not-send="true"
href="http://reviews.llvm.org/D15512">here's a proposed
fix</a>.</div>
</div>
</div>
</div>
</blockquote>
Commented on your review. <br>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
Reasonable. <br>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@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">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>
</div>
</div>
</blockquote>
It looks like the backend scalarizes a non-atomic <256 x i1>
store into 256 1 byte stores. So no, that can't be atomic. :)<br>
<br>
The particular lowering is also terrible. We should be emitting a
small loop in this case, not unrolling the entire thing. <br>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@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"> 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>
</div>
</div>
</blockquote>
Any clue how to start specifying this? It would seem to be ABI
dependent. <br>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@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"><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>
</div>
</div>
</blockquote>
"global atomic lock shard"? I have no idea what you're referring
to. Is that something in libc?<br>
<blockquote
cite="mid:CABdywOcexegXHJOW1U6fZEexJMt74xJ8GHgMhYRttqJ4=D7_Zg@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"> 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? ;-) <br>
</div>
</div>
</div>
</div>
</blockquote>
True. :)<br>
<br>
Philip<br>
<br>
</body>
</html>