<div dir="ltr"><div><font color="#500050"><span style="font-size:12.8px">Does anyone know where I can find code, or a rule set, which reliably</span></font></div><div><font color="#500050"><span style="font-size:12.8px">indicates whether or not two llvm GlobalVariables, or two llvm Functions,</span></font></div><div><font color="#500050"><span style="font-size:12.8px">could potentially be unified by the linker based on their attributes such</span></font></div><div><font color="#500050"><span style="font-size:12.8px">as linkage-type, visibility, const-ness, 'unnamed_addr`, and initializers?</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">I'm working on my own AA pass, and it will be unsound if I falsely conclude</span></font></div><div><font color="#500050"><span style="font-size:12.8px">that two GlobalVariables or two Functions name distinct pieces of memory,</span></font></div><div><font color="#500050"><span style="font-size:12.8px">when in fact that name identical or intersecting regions of memory.</span></font></div><div><font color="#500050"><span style="font-size:12.8px">False-positives degrade my precision, but false-negatives make my algorithm</span></font></div><div><font color="#500050"><span style="font-size:12.8px">unsound.</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">David Majnemer kindly pointed to the method areGlobalsPotentiallyEqual(...)</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><<a href="http://llvm.org/docs/doxygen/html/ConstantFold_8cpp_source.html#l01382">http://llvm.org/docs/doxygen/html/ConstantFold_8cpp_source.html#l01382</a>>,</span></font></div><div><font color="#500050"><span style="font-size:12.8px">but it looks like it gives up easily when external or weak linkage is</span></font></div><div><font color="#500050"><span style="font-size:12.8px">involved, so I didn't know if one could do better with a little more effort.</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">In my case, the current version of clang will always be the front-end, but</span></font></div><div><font color="#500050"><span style="font-size:12.8px">the back-end might not be ELF, so I hesitate to draw too many conclusions</span></font></div><div><font color="#500050"><span style="font-size:12.8px">just from the GNU assembly I see produced on my system for the little test</span></font></div><div><font color="#500050"><span style="font-size:12.8px">cases I come up with.</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">Note: This is a re-post related to a few threads on llvm-dev, because no</span></font></div><div><font color="#500050"><span style="font-size:12.8px">one there seemed to have a definitive answer, and I thought clang folks may</span></font></div><div><font color="#500050"><span style="font-size:12.8px">have run into this.</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><a href="http://lists.llvm.org/pipermail/llvm-dev/2015-November/092116.html">http://lists.llvm.org/pipermail/llvm-dev/2015-November/092116.html</a></span></font></div><div><font color="#500050"><span style="font-size:12.8px"><a href="http://lists.llvm.org/pipermail/llvm-dev/2015-November/092221.html">http://lists.llvm.org/pipermail/llvm-dev/2015-November/092221.html</a></span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">Thanks,</span></font></div><div><font color="#500050"><span style="font-size:12.8px">Christian</span></font></div></div>