There are good placement decision algorithms based on profile data (real and static).  It is a max flow problem solvable by very simple solvers.<div><br></div><div>So if this becomes a real problem, we could solve it.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 29, 2017, 9:00 PM Philip Reames via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">reames added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D38392#885147" rel="noreferrer" target="_blank">https://reviews.llvm.org/D38392#885147</a>, @danielcdh wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D38392#885134" rel="noreferrer" target="_blank">https://reviews.llvm.org/D38392#885134</a>, @reames wrote:<br>
><br>
> > In <a href="https://reviews.llvm.org/D38392#885108" rel="noreferrer" target="_blank">https://reviews.llvm.org/D38392#885108</a>, @danielcdh wrote:<br>
> ><br>
> > > I see your point now. My concern is performance: if we allow hoisting of atomic load, but not allow sinking it, we may end up with bad performance as we may have too much redundant atomic loads in the preheader. Any suggestions on how to solve that?<br>
> ><br>
> ><br>
> > Not really.  I can say that we've been running performance tests for months in this configuration (LICM hoisting unordered loads, no LoopSink) without noticing any problems.  I'm not immediately concerned.<br>
><br>
><br>
> Sorry, not sure if I follow the logic, could you explain why you don't think this is a performance concern?<br>
<br>
<br>
I acknowledge it's a potential issue.  I have no good ideas for a solution.  I don't believe it's a current problem and evidence to believe that it's relatively minor.  (i.e. we haven't seen it)<br>
<br>
<br>
<a href="https://reviews.llvm.org/D38392" rel="noreferrer" target="_blank">https://reviews.llvm.org/D38392</a><br>
<br>
<br>
<br>
</blockquote></div></div>