<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 15, 2015 at 4:27 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<br>
<br>
<div>On 12/15/2015 04:21 PM, JF Bastien
wrote:<br>
</div>
<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"><span>
<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"><span>
<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"><span>
<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>
</span> "global atomic lock shard"? I
have no idea what you're referring to. Is
that something in libc?</div>
</blockquote>
<div><br>
</div>
<div>compiler-rt: <a href="https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c" target="_blank">https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c</a></div>
</div>
</div>
</div>
</blockquote>
</span> Hm, I think this raises an interesting semantic
question. We could use the global lock shard scheme to
make loads atomic w.r.t. other llvm emitted writes, but
not writes emitted by other compilers. This would mean
that linking object files with atomics might break their
atomicity. I'm not sure we want to allow that. Maybe
we can do that only if the synchronization scope allows
it or something?</div>
</blockquote>
<div><br>
</div>
<div>GCC does it in libatomic: <a href="https://github.com/gcc-mirror/gcc/tree/master/libatomic" target="_blank">https://github.com/gcc-mirror/gcc/tree/master/libatomic</a></div>
<div><br>
</div>
<div>They agree on the function name, so AFAIK either
runtime allows this to work properly: the compiler just
emits a call to the function, and one of the runtimes has
to be present.</div>
</div>
</div>
</div>
</blockquote></div></div>
Do they end up using the same lock though? If not, we'd still have
a race and break atomicity. <br></div></blockquote><div><br></div><div>I believe this is the intent.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Also, what about the case of partially overlapping accesses? The
code you linked to seems to only handle the case where the base and
size of the access regions match exactly. <br></div></blockquote><div><br></div><div>That would be UB :-) </div></div></div></div>