<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 10:30 AM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Wei,<br>
<br>
The short story is: I do not think this is the way to go.<br>
<br>
Now, the long story.<br>
<br>
I have mixed feelings on the direction of the approach. On one hand, I also think we should optimize for performance as long as register pressure is not a problem. On the other hand, the register pressure estimate at this level too rough to make any useful decisions.<br></blockquote><div><br></div><div>That is a pretty strong statement (about usefulness of register pressure estimate) :)   I think it is probably reasonably good for cases where pressure is very low and very high -- and this part can be improved independently. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your current approach illustrate this point. Indeed, IIRC NumRegs only gives you the number of registers you need to materialize the formulae, we do not consider how many register we already need in the loop or through the loop. Therefore, I believe by tweaking the body of the loop in your motivating example (i.e., adding just enough live ranges), we can bloat the register pressure with the new rating and have spill within the loop, whereas we wouldn’t with the previous rating.<br></blockquote><div><br></div><div>If we don't want spills, but spills occur, then it is matter of tuning register pressure estimation -- can even be made more conservative. In fact, if we consider spills in the overall cost, we can even deliberately allow some spills to reduce overall cost (but that requires very precise pressure estimate).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I also mentioned that in the related PR, but I believe the way to go is: not to care on register pressure and just rate the cost of the loop body. However, this implies the backends are able to recover from the register pressure bloat and I believe we are not quite here.<br>
<br></blockquote><div><br></div><div>The cost should include 'potential' spills due to register pressure.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*How do we move?<br>
<br>
I would suggest we add an internal option to make LSR more aggressive w.r.t. to register pressure, and fix all the problems that rise in the backends. Then, we can turn that option on by default.<br></blockquote><div><br></div><div>We want to generate optimal code sequence with minimal cost --- that is not equivalent to 'the most aggressive LSR'.   Do we already know possible ways to fix the problem once the damage is already made (high reg pressure ...)?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- What if other people still believe this is the right way to move?<br>
<br>
Like I said, I do not think this is the right way to go. Now, if other people believe it is, I would at least expect that you supply more details numbers. In particular, what are the actual numbers (not just the geometric means) and what are the regressions, why we do not care or how do we plan to fix them.<br></blockquote><div><br></div><div>I suggest Wei to refactor the change in a way so that it can be turned on/off with an option. When that is ready, the community can help with the performance testing on their favorite platforms with their favorite benchmarks. It may turns out to be better for everyone, who knows :)</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
-Quentin<br>
<span class="im HOEnZb"><br>
<br>
REPOSITORY<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D9429" target="_blank">http://reviews.llvm.org/D9429</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>