<div dir="ltr"><div><div><div>Hi Ben,<br><br></div>I'm interested in disabling *all* optimizations across a given machine instruction, not just load/store movement. Basically I'm hoping to limit the scope of optimizations so that at certain points in the application code, the execution state (i.e., registers & stack) can be directly mapped between architecture-specific layouts. Additionally, by putting boundaries around optimizations we can ensure that computation has reached a semantically equivalent point. Optimizations which create architecture-specific live values or which perform code movement make it much harder to find these "equivalence points". If there was a way to put boundaries around instructions, we could programmatically create equivalence points.<br><br></div>I realize that hard boundaries like I'm describing may be too strong of a requirement, so I think I can work around optimizations which create live values known at compile-time, i.e., references to global values/stack objects or immediates. Just as a little more context, I'm using LLVM's <a href="http://llvm.org/docs/StackMaps.html">stackmap intrinsic</a> to capture live value locations. The stackmap already restricts memory movement around the intrinsic's location.<br><br></div>Thanks!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 12:55 PM, Ben Craig <span dir="ltr"><<a href="mailto:ben.craig@ni.com" target="_blank">ben.craig@ni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_2833188254294928401WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It depends on what kinds of optimizations you want to turn off. An easy (and heavy weight) thing to do to prevent memory optimizations from crossing a boundary is to insert
sequentially consistent memory barriers. However, if the optimizer has determined that a given values address hasn’t escaped to another thread, then operations on that value won’t qualify as a memory operation, and it will still be able to travel across the
memory barrier.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@<wbr>lists.llvm.org</a>]
<b>On Behalf Of </b>Rob Lyerly via llvm-dev<br>
<b>Sent:</b> Thursday, June 29, 2017 11:09 AM<br>
<b>To:</b> Rob Lyerly via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [llvm-dev] Optimization Barrier in LLVM Backends<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div><span class="">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hello,<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Is it possible to prevent optimizations across a given machine instruction, i.e., some sort of "optimization barrier", when doing architecture-specific optimizations during code generation? For example, I'd
like to be able to insert some form of instrumentation prevent an optimization pass from lifting a common sub-expression across a given machine instruction.<u></u><u></u></p>
</div>
<p class="MsoNormal">I'm interested in capturing and maintaining an equivalent set of live values across compilations for different architectures, similarly to what is expressed in "A Unified Model of Pointwise Equivalence of Procedural Computations" (<a href="http://dl.acm.org/citation.cfm?id=197402" target="_blank">http://dl.acm.org/citation.<wbr>cfm?id=197402</a>).
Architecture-specific optimizations very often create architecture-specific live values, which makes it hard to map live values between different architectures.<br clear="all">
<u></u><u></u></p>
</span><div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for any help!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><span class="">
<div>
<p class="MsoNormal">Rob Lyerly<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Graduate Research Assistant, Systems Software Research Group<u></u><u></u></p>
</div>
</span><div>
<p class="MsoNormal"><span style="border:solid windowtext 1.0pt;padding:0in"><img style="width:.7187in;height:.7187in" id="m_2833188254294928401_x0000_i1025" src="cid:image001.jpg@01D2F0CE.A446FA90" alt="Image removed by sender." width="69" height="69" border="0"></span> <span style="border:solid windowtext 1.0pt;padding:0in"><img style="width:.0833in;height:.677in" id="m_2833188254294928401_x0000_i1026" src="cid:image002.jpg@01D2F0CE.A446FA90" alt="Image removed by sender." width="8" height="65" border="0"></span>
<span style="border:solid windowtext 1.0pt;padding:0in"><img style="width:4.9687in;height:.625in" id="m_2833188254294928401_x0000_i1027" src="cid:image003.jpg@01D2F0CE.A446FA90" alt="Image removed by sender." width="477" height="60" border="0"></span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><span>Rob Lyerly</span><br></div><div>Graduate Research Assistant, Systems Software Research Group<br><br></div><div><img src="https://www.branding.unirel.vt.edu/content/branding_unirel_vt_edu/en/trademarks/index/jcr:content/content/vtmulticolumn/vt-items_2/adaptiveimage.img.3008.low.jpg/1461259021506.jpg" width="69" height="69"> <span><span><span><span><img src="http://www.oocities.org/rainforestwind/divider_black_vertical.jpg" width="8" height="65"></span></span></span></span> <img src="https://docs.google.com/uc?id=0B8E5oZB3WuGKTDNXVkt6UlFja1k&export=download" width="477" height="60"></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>