Use intrinsics for non-temporal loads.

[ruriww]

Fixes #2155

Blocked on

• LLVM intrinsics (llvm.x86.sse41.movntdqa) does not work https://godbolt.org/z/9z5YhnWMW
• Need to implement core::intrinsics::nontemporal_load

[workingjubilee]

So, I believe this can go ahead, but you should probably include a comment as to why it is sound/correct to implement the MOVNTDQA intrinsics this way even though the store side is implemented with asm!

I recommend consulting the Intel Software Developer's Manual, including its excerpted versions like https://www.felixcloutier.com/x86/movntdqa

Basically, the argument you want to make is that fetching the memory doesn't have any unusual behaviors because it still has to correctly manage the cache at the time of the read, and that there is no way to do something like write to the memory that will not synchronize with the reads.

You especially will want to explain what the relevance is of this part and why the MFENCE obligation only appears in the case of a non-temporal store appearing with a non-temporal load (or doesn't appear? slightly unclear).

Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with a MFENCE instruction should be used in conjunction with MOVNTDQA instructions if multiple processors might use different memory types for the referenced memory locations or to synchronize reads of a processor with writes by other agents in the system. A processor’s implementation of the streaming load hint does not override the effective memory type, but the implementation of the hint is processor dependent. For example, a processor implementation may choose to ignore the hint and process the instruction as a normal MOVDQA for any memory type. Alternatively, another implementation may optimize cache reads generated by MOVNTDQA on WB memory type to reduce cache evictions.

Importantly, the way we interact with write-combining memory is mmmostly irrelevant to Rust's opsem since we don't usually admit such memory regions into our model. It only matters here because the nontemporal hints, at least on stores, treat normal memory as WC memory. My scan of the text suggests they do similar on loads, but that the reason we can use LLVM's "native" handling of nontemporal here is because it's inherently nonproblematic.

That is, as x86 is a "total store order" architecture, it doesn't have the inherent problem of "stores must synchronize with each other, because atomic ops can be legalized to normal stores by LLVM, so a class of store that doesn't synchronize with other stores can't be admitted to the memory model and must be performed using a bizarre rationale, in non-Rust code, in ways that make it so LLVM can't merge it with other loads".

[workingjubilee]

and yes I did just make most of the argument for you, but like fill in any details and make it more concise like I didn't. :3