<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021 at 4:37 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_4678177126340148836WordSection1">
<p class="MsoNormal">GlobalsAAResult::getModRefInfo only analyzes globals whose address isn’t taken.  The reasoning goes something like this: suppose you have a global which is only loaded/stored directly.  Then the value can only be accessed by the functions
 which contain those instructions, and any function that calls those functions.  It can’t be accessed by any other function.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Looping over the arguments in getModRefInfoForArgument, as far as I can tell, does nothing useful.  We only call into this code for globals whose address isn’t passed to any calls, so the call’s arguments aren’t relevant: we already know
 they don’t alias the global.  It looks like it’s the remains of an attempt a few years ago to do some sort of more elaborate escape tracking in GlobalsAA.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Anyway, there’s a different hole in the logic if there’s more than one thread involved.  If the global might be accessed from another thread, we also need to ensure that the function doesn’t act as a synchronization barrier.  If there’s
 a barrier, it could guard a modification of the value by another thread.  To fix this hole, I think the code needs to check for a “nosync” attribute on the call.</p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">After a bit of poking, I think the problem starts even earlier, in AliasAnalysis.cpp. That's where `fence` instructions are handled (and are treated as RefMod). Treating convergent instrinsics that may modify memory in a similar way appears to fix the miscompile. It's probably overly conservative, but should do the job for now.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><a href="https://reviews.llvm.org/D115302">https://reviews.llvm.org/D115302</a></div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">--Artem</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_4678177126340148836WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Eli<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Artem Belevich via llvm-dev<br>
<b>Sent:</b> Tuesday, November 30, 2021 12:01 PM<br>
<b>To:</b> Nikita Popov <<a href="mailto:nikita.ppv@gmail.com" target="_blank">nikita.ppv@gmail.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [llvm-dev] Possible GlobalModRef bug -- arg-less calls produce wrong ref info.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">Hi Nikita,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">I've been tracking a miscompile in NVPTX which I've narrowed down to this oddity, where GlobalModRef gives different answers depending on whether an intrinsic call has an argument or not:<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif"><a href="https://godbolt.org/z/4PqhWKha5" target="_blank">https://godbolt.org/z/4PqhWKha5</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">The difference in behavior appears to originate here:<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif"><a href="https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/GlobalsModRef.cpp#L908" target="_blank">https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/GlobalsModRef.cpp#L908</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">If the intrinsic has no arguments, it always returns `NoModRef`.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">This allows LLVM to eliminate loads and stores that should have been preserved.<u></u><u></u></span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif"><u></u> <u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Verdana,sans-serif">I'm not sure it's the real root cause, though. Supposedly the purpose of the `getModRefInfoForArgument` function is to tell whether the argument references the value, so technically, if there's
 no argument, there's no reference.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_4678177126340148836gmaildefault"><span style="font-family:Verdana,sans-serif">It's possible that the real issue is that something/somewhere ignores the function attributes (or, rather, lack or readonly/writeonly, argmemonly, etc) and we've
 just been lucky to have things working correctly for the intrinsics *with* an argument only because `</span></span><span style="font-family:Verdana,sans-serif">getModRefInfoForArgument<span class="gmail-m_4678177126340148836gmaildefault">` would give a conservative answer when we
 use a scalar value.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I<span class="gmail-m_4678177126340148836gmaildefault"><span style="font-family:Verdana,sans-serif">'m not familiar with AA machinery and could use your help figuring out what's going on.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_4678177126340148836gmaildefault"><span style="font-family:Verdana,sans-serif">Thank you,</span></span><u></u><u></u></p>
</div>
<p class="MsoNormal">--<span class="gmail-m_4678177126340148836gmaildefault"><span style="font-family:Verdana,sans-serif">Artem</span></span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--Artem Belevich</div></div></div>