<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 15, 2016 at 12:15 AM, JF Bastien <span dir="ltr"><<a href="mailto:jfb@google.com" target="_blank">jfb@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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">
            <div>What exactly would the non-temporal fences be?  It
              seems that on x86, the load and store case may differ.  In
              theory, there's also a before vs. after question.  In
              practice code using MOVNTA seems to assume that you only
              need an SFENCE afterwards.  I can't back that up with spec
              verbiage.  I don't know about MOVNTDQA.  What about ARM?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I'll leave this to JF to answer.  I'm not knowledgeable enough about
    non-temporals to answer without substantial research first.<br></div></blockquote><div><br></div></span><div>I'm proposing two builtins:</div><div><li>__builtin_nontemporal_load_fence</li><li>__builtin_nontemporal_store_fence</li></div><div><br></div><div>I've I've got this right, on x86 they would respectively be a nop, and sfence.</div><div><br></div><div>They otherwise act as memory code motion barriers unless accesses are proven to not alias. I think it may be possible to loosen the rule so they act closer to acquire/release (allowing accesses to move into the pair) but I'm not convinced that this works for every ISA so I'd err on the side of caution (since this can be loosened later).</div></div><br></div></div></blockquote><div>What would the semantics be?  They restore the normal architectural ordering guarantees relied upon by the synchronization primitives, so that non-temporal accesses don't need to be considered when  implementing synchronization?</div><div><br></div><div>Then I think an SFENCE following x86 non-temporal stores would be correct. And empirically we don't need anything to before a non-temporal store to order it with respect to earlier normal stores.  But I don't the latter conclusion follows from the spec.</div><div><br></div><div>I looked at the MOVNTDQA non-temporal load documentation again, and I'm confused.  It sounds like so long as the memory is WB-cacheable, we may be OK without any fences.  But I can't tell that for sure.  In the WC case, a LOCKed instruction seems to be documented to work as a fence.</div><div><br></div><div>In the ARM LDNP case, things seem to be messy.  I don't think we currently need fences for C++, since we don't normally use the dependency-based ordering guarantees.  (Except to prevent out-of-thin-air results, which don't seem to be precluded by the ARM spec.  Intentional or bug?)  But the difference does matter when implementing Java final fields or memory_order_consume.</div><div><br></div><div>I'm actually getting a little worried that these things are just too idiosynchratic to reflect in portable intrinsics.</div></div></div></div>