<div dir="ltr"><div dir="auto">I would say there are transforms that can be done on atomics that can't be done on volatile memory ops. For example, llvm should be able to mem2reg unescaped atomics because it knows they cannot be modified by other threads, but volatile operations will pin things in memory for use cases that are mostly outside the abstract model.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 20, 2017, 7:26 AM Paweł Batko via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi llvm-dev,<br>
<br>
I read about volatile and atomic modifiers in the docs[1], and I feel<br>
they make sense to me individually.<br>
However, I noticed that store[2] and load[3] instructions can be<br>
marked as both volatile and atomic.<br>
<br>
What's the use case for using both volatile and atomic on an<br>
instruction? Isn't it the case that atomic implies volatile? I guess<br>
it isn't, but I don't understand why.<br>
<br>
I'm guessing that while both volatile and atomic restrict reorderings,<br>
volatile prevents any kind of load or store elimination optimizations<br>
but atomic doesn't have such guarantee.<br>
E.g. I suspect that an atomic load, which can be implemented as a pair<br>
of a plain load and a fence instruction, can be optimized away to only<br>
a fence instruction. If it was both volatile and atomic, then such<br>
optimization would've been illegal.<br>
In other words, probably very imprecisely, volatile tells the compiler<br>
what it cannot do while atomic tells the cpu what it should do to<br>
guarantee certain memory model (and it'd also imply extra constraints<br>
on what a compiler can do).<br>
<br>
My other guess is that it's only to order 'atomic' instruction with<br>
'volatile' instruction, thus the former becomes 'atomic volatile'.<br>
<br>
I'd appreciate links to any resources on the topic.<br>
<br>
<br>
[1] <a href="https://llvm.org/docs/LangRef.html#volatile-memory-accesses" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.<wbr>html#volatile-memory-accesses</a><br>
[2] <a href="https://llvm.org/docs/LangRef.html#store-instruction" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.<wbr>html#store-instruction</a><br>
[3] <a href="https://llvm.org/docs/LangRef.html#i-load" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.<wbr>html#i-load</a><br>
<br>
--<br>
Paweł Batko<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>