<html><body><p>I guess it clear, but to be sure, the numbers are percentage of the compile time slow down after applying the patch: ((After - Before) / Before)<br><br><br><img width="16" height="16" src="cid:1__=8FBB0A99DFC9BFBE8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Ehsan A Amiri---08/09/2016 12:24:34 PM---I have measured the impact of throwing away cache (Daniel's "><font color="#424282">Ehsan A Amiri---08/09/2016 12:24:34 PM---I have measured the impact of throwing away cache (Daniel's patch) on the compile time. I used a sub</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Ehsan A Amiri/Toronto/IBM</font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Daniel Berlin <dberlin@dberlin.org></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Hal Finkel <hfinkel@anl.gov>, llvm-commits <llvm-commits@lists.llvm.org>, reviews+D22305+public+92ca108e50bc4651@reviews.llvm.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">08/09/2016 12:24 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [PATCH] D22305: [BasicAA] Strip phi nodes, when all incoming values are the same.</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br>I have measured the impact of throwing away cache (Daniel's patch) on the compile time. I used a subset of CPU 2006 benchmarks. I only compiled C/C++ files, for the benchmarks that had some fortran files. <br><br>This is the result: There are two significant slow downs: namd (16%) and h264ref (9%). for the rest please see bottom of the email.<br><br>So between the following two, I believe first we want to give a try to (1) before measuring the impact of (2). Is that correct?<br><br>(1) removing only clobber entries from the cache.<br>(2) fixing BasicAA to work better with phi-s with a unique incoming value.<br><br>For (1) I do not have any intuition into how much it will save. I know for local cache we cache the result when there is no dependency found. I don't remember how the global cache works.<br><br><br>astar 1.6<br>bzip2 3.5<br>cactus 3.2<br>calculix 2.5<br>gcc 4.6<br>gobmk 1.5<br>gromacs 4.3<br>hmmer 3.3<br>mcf 1.3<br>perlbench 3.2<br>povray 3.1<br>soplex 1.9<br><br><br><br><br><br><br><br><img width="16" height="16" src="cid:1__=8FBB0A99DFC9BFBE8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Daniel Berlin ---07/15/2016 05:22:27 PM---On Fri, Jul 15, 2016 at 1:34 PM, Ehsan A Amiri <amehsan@ca."><font color="#424282">Daniel Berlin ---07/15/2016 05:22:27 PM---On Fri, Jul 15, 2016 at 1:34 PM, Ehsan A Amiri <amehsan@ca.ibm.com> wrote: > So I will first experim</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Daniel Berlin <dberlin@dberlin.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Ehsan A Amiri/Toronto/IBM@IBMCA</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Hal Finkel <hfinkel@anl.gov>, llvm-commits <llvm-commits@lists.llvm.org>, reviews+D22305+public+92ca108e50bc4651@reviews.llvm.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">07/15/2016 05:22 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [PATCH] D22305: [BasicAA] Strip phi nodes, when all incoming values are the same.</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><br><br><font size="4">On Fri, Jul 15, 2016 at 1:34 PM, Ehsan A Amiri <</font><a href="mailto:amehsan@ca.ibm.com" target="_blank"><u><font size="4" color="#0000FF">amehsan@ca.ibm.com</font></u></a><font size="4">> wrote:</font><ul><font size="4">So I will first experiment with (3). If we don't like the outcome, then we can experiment with (2) to see how feasible is that.<br></font><b><font size="4"><br>Daniel</font></b><font size="4">: Thanks for the response to my question. But now I need to ask two more question to understand things:<br></font><i><font size="5"><br>As mentioned, in your testcase, there is another bug here. Remember that GVN iterates until things stop changing. So *the first gvn pass* should have never left the IR with that redundant PHI node in the first place.</font></i><font size="4"><br></font><font size="5"><br>1- IIUC, we are saying that at the end of one GVN iteration, the IR should satisfy some properties. Is it possible to describe this properties? </font></ul><br><br><font size="4">Close. I mean "at the end of executing a GVN pass, the IR should satisfy some properties" (iterations are internal to gvn, and in the current GVN, it may take multiple iterations to satisfy these properties).</font><br><br><font size="4">The properties it should satisfy are[1]</font><br><br><font size="4">1. Every value (V) dominated by another provably equivalent value (Leader) should have V replaced by Leader. This is "equivalence without taking into account conditionals", and not even complete equivalence, but "equivalence that this GVN algorithm can detect". The GVN algorithm used is not a complete one, so it misses plenty of provably equivalences.</font><br><br><font size="4">As a trivial example:</font><br><br><font size="4">for (int i =0, j = 0; i < 50; ++i, ++j)</font><br><font size="4">{</font><br><font size="4">int x = i + 2;</font><br><font size="4">int y = j + 2;</font><br><font size="4">A[x] = y</font><br><font size="4">int z = A[y];</font><br><font size="4">}</font><br><br><font size="4">i, j, x, y, z are all equivalent.</font><br><font size="4">Current GVN will detect none of these. This is not fixable.</font><br><br><font size="4">NewGVN is not complete, but it will detect all of these.</font><br><font size="4">Complete algorithms will detect all that can be detected :)</font><br><br><font size="4">2. Every instruction should be simplified as done by SimplifyInst. If simplification produces a value, all uses should be replaced with that simplified value</font><br><br><font size="4">[1] There are PRE and conditional propagation properties, but they are harder to describe.</font><br><br><font size="4">Now, for *each iteration*, there are invariants. The above is an iteration level invariant except for the case where it does PRE and inserts code. In the case it does PRE and inserts code, it may not meet the above conditions.</font><br><br><br><font size="4"> </font><br>
<ul><font size="5"><br>2- I suspect that the "other bug" that you are talking about is a GVN bug. Could you elaborate on that if this is correct?</font></ul><br><font size="4">Yes.</font><br><font size="4"> </font><ul><font size="5">IIRC from my debugging, the redundant phi node was created and deleted in iteration 0 of GVN.</font></ul><br><font size="4"> I do not see this happen in some cases where i modify your testcase.</font><br><font size="4">Again i was not being precise enough, and meant more "things your testcase exposes after debugging the code".</font><br><br><font size="4"> </font><ul><font size="5">It was just that cache issue that happened between the creation and deletion of redundant phi node that caused this....</font><font size="4"><br></font><font size="5"><br>Thanks<br>Ehsan</font><font size="4"><br><br><br><br></font><img src="cid:1__=8FBB0A99DFC9BFBE8f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive hide details for Daniel Berlin ---07/15/2016 04:08:45 PM---> >"><font size="4" color="#424282">Daniel Berlin ---07/15/2016 04:08:45 PM---> ></font><font size="4"><br></font><font color="#5F5F5F"><br>From: </font>Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank"><u><font color="#0000FF">dberlin@dberlin.org</font></u></a>><font color="#5F5F5F"><br>To: </font>Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank"><u><font color="#0000FF">hfinkel@anl.gov</font></u></a>><font color="#5F5F5F"><br>Cc: </font>llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-commits@lists.llvm.org</font></u></a>>, <a href="mailto:reviews%2BD22305%2Bpublic%2B92ca108e50bc4651@reviews.llvm.org" target="_blank"><u><font color="#0000FF">reviews+D22305+public+92ca108e50bc4651@reviews.llvm.org</font></u></a>, Ehsan A Amiri/Toronto/IBM@IBMCA<font color="#5F5F5F"><br>Date: </font>07/15/2016 04:08 PM<font color="#5F5F5F"><br>Subject: </font>Re: [PATCH] D22305: [BasicAA] Strip phi nodes, when all incoming values are the same.<br><hr width="100%" size="2" align="left" noshade style="color:#000000; "><font size="4"><br></font><ul><ul><br><font size="5" face="Arial"><br>Or do we need (2) because in general this kind of phi node is seen in many programs? Or something else that I do not see....</font><p><font size="5" face="Arial"><br>That is hal's view.</font><p><font size="4" face="Arial">My view was that we should measure the impact of the change and then decide; but that if we have a use case for it, I'd rather it be inside the generic utility than a specific work-around in BasicAA.</font></ul></ul><font size="5"><br>Yes, sorry, was writing quickly, did not mean to imply anything else ;)</font><font size="4"><br><br></font></ul><br>
<p><BR>
</body></html>