<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"><div>I agree that it's fine to use a locked instruction as a
              seq_cst fence if MFENCE is not available.  </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    It's not clear to me this is true if the seq_cst fence is expected
    to fence non-temporal stores.  I think in practice, you'd be very
    unlikely to notice a difference, but I can't point to anything in
    the Intel docs which justifies a lock prefixed instruction as
    sufficient to fence any non-temporal access.  <br></div></blockquote><div><br></div><div>Correct, that's why changing the memory model is critical: seq_cst fence wouldn't have any guarantee w.r.t. non-temporal.</div><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"><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><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>