<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"><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">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>