<div dir="ltr"><div dir="ltr">On Tue, 18 Aug 2020 at 14:36, Florian Hahn via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that both the current and MemorySSA-backed DSE implementations rely on various thresholds to avoid excessive compile-times. There are a few knobs to turn to further reduce compile-time of the MemorySSA-backed DSE implementation, at the cost of missing to eliminate some stores.The current settings are chose so the compile-time difference is limited without limiting optimizations too much.<br></blockquote><div><br></div><div><div>Did you compare the new algorithm with the knobs down enough to take roughly the same compile time as the old one? </div><div></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">b) Switch to memorySSA-backed DSE, but use more aggressive limits. For some configurations (e.g. limit optimizations for -O2/-Os)<br>
c) Switch to MemorySSA-backed DSE in some configurations (e.g. -O3/-Oz only)</blockquote><div><br></div><div>If we do switch, and I'm not advocating for that yet, I'd do a mix of those. </div><div><br></div><div>Use slightly more aggressive limits at O2, those limits at O3 and perhaps add an extra argument to push even further for people who really need it and can pay the extra compile time.</div><div><br></div><div>--renato</div></div></div>