<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 27, 2017 at 1:42 PM, Wei Mi via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Thu, Apr 27, 2017 at 1:26 PM, Daniel Berlin via Phabricator<br>
<<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br>
> dberlin added a comment.<br>
><br>
> Isn't this close to what n-ary reassociate does?<br>
> (if so, why not just use that and disable this?)<br>
><br>
<br>
</span>Nary reassociate tries to maximize the redundency exposed by<br>
reassociation. </blockquote><div><br></div><div>As does reassociate :)</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">This patch tries to reduce the register pressure by<br>
changing where to insert the intermediate results of reassociation,<br>
and it doesn't try to improve the result of reassociation for better<br>
CSE/PRE/LICM optimizations. </blockquote><div><br></div><div>I understand.</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">The two have different motivations, so I<br>
don't see how nary reassociation can be helpful here.<br></blockquote><div><br></div><div>The placement algorithm for computations that n-ary reassociate uses tries to reuse existing computation points.</div><div>This patch tries to fix  "<span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui emoji","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px">too many overlapped life-ranges.</span><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui emoji","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> "</span></div><div><br></div><div>The algorithm it uses, to find nearest common dominator of operands, etc, is pretty much what n-ary reassociate does:</div><div>"</div><div><div>  // Look for the closest dominator LHS of I that computes LHSExpr, and replace</div><div>  // I with LHS op RHS.</div></div><div>"</div><div><br></div><div><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui emoji","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui emoji","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui emoji","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> <a href="https://reviews.llvm.org/D32563" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D32563</a><br>
><br>
><br>
><br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>