<div dir="ltr"><div>Thanks for your explanation. </div><div><br></div>Do you mean that LLVM will not maintain the def-use chain for atomic variables?<div>So it is impossible to directly catch the fact that the load of x at the statement 'data1 = x; ' dependents on data4 (because of the statement x=data4 )? <br></div><div><div>If I want to get such information, may be the only solution is to traverse all the predecessors of the statement 'data1 = x;'. <br class="gmail-Apple-interchange-newline"><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Best regards,</div><div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Qiuping Yi</div><div style="font-size:12.8px"><span style="font-size:12.8px">Institute Of Software</span><br style="font-size:12.8px"><span style="font-size:12.8px">Chinese Academy of Sciences</span><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Feb 8, 2018 at 3:11 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8 Feb 2018, at 04:07, Qiuping Yi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I found that it only generated PHI node (%8 = phi i32 [ %4, %3 ], [ %6, %5 ]) for non-atomic variable 'data2' but not for atomic variable x? Why?<br>
<br>
</span>LLVM IR does not contain variables, it contains (immutable) registers.  Some of these registers refer to memory locations and are usable with loads and stores.  The notion of ‘atomic’ doesn’t make sense in the context of a register, because registers are implicitly immutable (i.e. not updated, so atomic updates don’t make sense) and non-shared (so there’s nothing for accesses to them to be atomic with respect to).  As such, the atomic qualifier makes sense only with memory locations.  The memory address itself may be stored in a register, but updates to the location must be performed by loads and stores (or atomicrmw instructions).<br>
<br>
In the absence of any ordering constraints imposed by atomic memory operations (including fences), it is often safe to promote a sequence of loads and stores of a memory location to a single load / store pair with a sequence of registers storing temporary values.  This is allowed because, in the absence of something that establishes a happens-before relationship between threads, a thread is allowed to make writes to memory visible to other threads in any order.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>