<div dir="ltr"><br><div>We call getModRefInfo on each instruction, and see what it says.</div><div>Here, atomic loads are said to modify memory.</div><div>This is because of ordering/other constraints, whicch are currently modeled by saying they are defs. This is done to be conservatively correct in LLVM and generally prevent passes from reordering them.</div><div>Otherwise, the use/def chains would say it was fine to move them in ways it may not be.</div><div>If we wanted to be super-precise, we would split the aliasing def-use chain and the ordering def-use chain.</div><div><br></div><div>If we did that, it would be a MemoryUse and an OrderingDef (or whatever we called them)</div><div>So far, that has not been worth doing.</div><div><br></div><div>You will also see the memoryssa, by default, will not disambiguate def->def chains (IE 5->6 in the above case. It requires introducing a multiple phi/variable form of memoryssa. Experience showed us this was not worth it. GCC now uses a single variable/phi form like we do). Use getClobberingMemoryAccess to disambiguate def-def chains if you need it.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 10:01 AM, Qiuping Yi <span dir="ltr"><<a href="mailto:yiqiuping@gmail.com" target="_blank">yiqiuping@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Daniel Berlin,<div><br></div><div>I just tried <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">MemorySSA analysis and get the next IR. </span></div><div>However, I feel confused by the result. </div><div><br></div><div>Specifically, why instruction <b>%3</b> relates to a <b>MemoryDef</b>. According to my understanding,</div><div>I think <b>%3</b> should be related to a <b>MemoryUse</b>, right?</div><div><br><div><br></div><div><span class=""><div>; Function Attrs: uwtable</div><div>define void @_Z2f1v() #3 personality i32 (...)* @__gxx_personality_v0 {</div></span><div>entry:</div><div>; 1 = MemoryDef(liveOnEntry)</div><span class=""><div> tail call void @checker_thread_begin(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i64 0, i64 0))</div></span><div>; MemoryUse(1)</div><div> %0 = load i32, i32* @data1, align 4, !tbaa !1</div><div> %cmp = icmp sgt i32 %0, 0</div><div> br i1 %cmp, label %if.then, label %entry.if.end_crit_edge</div><div><br></div><div>entry.if.end_crit_edge: ; preds = %entry</div><div>; MemoryUse(1)</div><div> %.pre = load i32, i32* @data2, align 4, !tbaa !1</div><div> br label %if.end</div><div><br></div><div>if.then: ; preds = %entry</div><div>; MemoryUse(1)</div><div> %1 = load i32, i32* @data4, align 4, !tbaa !1</div><div><b>; 2 = MemoryDef(1)</b></div><div><b> store atomic i32 %1, i32* getelementptr inbounds (%"struct.std::atomic", %"struct.std::atomic"* @x, i64 0, i32 0, i32 0) seq_cst, align 4</b></div><div>; 3 = MemoryDef(2)</div><div> store i32 %1, i32* @data2, align 4, !tbaa !1</div><div> br label %if.end</div><div><br></div><div>if.end: ; preds = %entry.if.end_crit_edge, %if.then</div><div>; 8 = MemoryPhi({if.then,3},{entry.i<wbr>f.end_crit_edge,1})</div><div> %2 = phi i32 [ %.pre, %entry.if.end_crit_edge ], [ %1, %if.then ]</div><div>; 4 = MemoryDef(8)</div><div> store i32 %2, i32* @data3, align 4, !tbaa !1</div><div><b>; 5 = MemoryDef(4)</b></div><div><b> %3 = load atomic i32, i32* getelementptr inbounds (%"struct.std::atomic", %"struct.std::atomic"* @x, i64 0, i32 0, i32 0) seq_cst, align 4</b></div><div>; 6 = MemoryDef(5)</div><div> store i32 %3, i32* @data1, align 4, !tbaa !1</div><div>; 7 = MemoryDef(6)</div><span class=""><div> tail call void @checker_thread_end()</div><div> ret void</div><div>}</div></span></div><div><br></div><div class="gmail_extra"><br clear="all"><span class=""><div><div class="m_6979692964152652238m_-1280618020354013905gmail_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></span><div class="gmail_quote"><span class="">On Thu, Feb 8, 2018 at 2:26 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div><br></div><div>Let me try to help.</div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Feb 8, 2018 at 12:13 PM, Qiuping Yi via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote></span><div>It is not a variable at the LLVM level.</div><div>At the source level, it is a variable.</div><div>At the LLVM IR level, it is lowered into memory operations.</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">All of your operations were. None of them are in llvm registers.</span><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Some were then promoted or partially promoted into registers.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(it looks like your output is -O1 or something and uses libstdc++ instead of libc++)</span></div><div>The loads are loads from a memory location. It does not have any more data dependence info than your atomics.<br></div><div><br></div><div>The phi you are seeing is not "LLVM giving you data dependence info".</div><div><br></div><div>Memory is not in SSA form in LLVM and has no def use chains by default.</div><div><br></div><div>If you want an SSA form for Memory, you would have to use the MemorySSA analysis.</div><span><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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="m_6979692964152652238m_-1280618020354013905m_-7059267137801284793m_-8773427658199693752gmail-Apple-interchange-newline"></div></div></div></blockquote><div><br></div></span><div>This will not work either in general.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><div><div><br></div></div></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_6979692964152652238m_-1280618020354013905m_-7059267137801284793m_-8773427658199693752gmail_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></span><span><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>On 8 Feb 2018, at 04:07, Qiuping Yi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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="m_6979692964152652238m_-1280618020354013905m_-7059267137801284793m_-8773427658199693752HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></span></div>
<br></span>______________________________<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>
<br></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></div></div>
</blockquote></div><br></div>