<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact. Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like splitting or remat could be hooked up and call an undo routine based on a cost model.<div class=""><br class=""></div><div class="">I think there is time to do something longer term. This particular instance can only be an issue under -fast-math.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Gerolf</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 1, 2015, at 9:27 AM, Sanjay Patel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Hi Haicheng,<br class=""><br class=""></div>We need to prevent the transform if it causes spilling, but I'm not sure yet what mechanism/heuristic we can use to do that.<br class=""></div>Can you file a bug report with a reduced test case?<br class=""><br class=""></div>Thanks!<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 1, 2015 at 9:10 AM, Haicheng Wu <span dir="ltr" class=""><<a href="mailto:haicheng@codeaurora.com" target="_blank" class="">haicheng@codeaurora.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="#0563C1" vlink="#954F72" lang="EN-US" class=""><div class=""><p class="MsoNormal">Hi Sanjay,<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">I observed some extra register spills when applying the reassociation pass on spec2006 benchmarks and I would like to listen to your advice. <u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">For example, function get_new_point_on_quad() of tria_boundary.cc in spec2006/dealII has a sequences of code like this<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">X=a+b<u class=""></u><u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">Y=X+c<u class=""></u><u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">Z=Y+d<u class=""></u><u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">There are many other instructions between these float adds. The reassociation pass first swaps a and c when checking the second add, and then swaps a and d when checking the third add. The transformed code looks like<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">X=c+b<u class=""></u><u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">Y=X+d<u class=""></u><u class=""></u></p><p class="MsoNormal">…<u class=""></u><u class=""></u></p><p class="MsoNormal">Z=Y+a<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">a is pushed all the way down to the bottom and its live range is much larger now. <u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Best,<span class="HOEnZb"><font color="#888888" class=""><u class=""></u><u class=""></u></font></span></p><span class="HOEnZb"><font color="#888888" class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Haicheng<u class=""></u><u class=""></u></p></font></span></div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>