<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 19, 2013, at 1:17 PM, Justin Holewinski <<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>Updated patch attached.<br><br></div>I've addressed the CSE during legalization issue. Now ordering is only propagated if the new node does not have an ordering (is zero), or has an ordering that is greater than the replaced node.<br>
<br></div>As for compile time, I think I may have had some other machine interference in the 8% figure. I can't reproduce that now, and both LLVM unit tests and LNT are not showing any statistically significant differences. I see some variation across runs in LNT, but it looks to be machine noise as I see both regressions and improvements in different benchmarks in different runs. I see +/- 0.5% in the unit tests, but that goes both ways. Both tests use release+asserts build.<br></div></blockquote><div><br></div><div><div>Your patch looks fine but doesn't go far enough. I'd like to add an IROrder field to SDNode (eventually we might be able to make it redundant with NodeId, although there would be temporary points at which nodes have to share an IROrder). That would remove any concerns about the compile-time of potentially frequent DenseMap lookup. But I really want to do it to help ensure that IROrder remains present and valid as a topological order. Then we don't need a "source order" scheduler at all, which would be really great. Just emit MIs for the selected nodes in place, and break some physreg interferences.</div><div><br></div><div>Ideally, anyone who creates an SDNode needs to track down the IROrder. Rather than propagating IROrder when we replace all uses, we would do it when we morph or CSE the node, similar to DebugLoc. Ensuring topological order is another aspect of the problem that can be dealt with later.</div><div><br></div><div>It's a big infrastructure project. But if you find any part of this plan will help you, progress toward that goal is welcome.</div><div><br></div><div>-Andy</div></div><div><br></div><blockquote type="cite"><div dir="ltr">
</div><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 19, 2013 at 1:07 PM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Tue, Mar 19, 2013 at 12:47 PM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div>On Tue, Mar 19, 2013 at 2:26 AM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com" target="_blank">evan.cheng@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Mar 18, 2013, at 2:02 PM, Justin Holewinski <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:<br>
<br></div><div><blockquote type="cite"><div dir="ltr">Compile-time impact is negligible for a release build on the unit tests. There is about an 8% impact with assertions enabled.</div></blockquote>
<div><br></div></div>Unit tests are much too small for measuring compile time. 8% for assertion build is massive. Why are there such large discrepancy?</div></blockquote><div><br></div></div><div>I've been trying to get measurements from LNT, but I'm getting too much run-to-run variation. A few benchmarks show significant changes (both positive and negative), but the affected benchmarks are different from run to run. The vast majority of benchmarks show no change. Do you have any suggestions for getting concrete compile time data?<br>
</div></div></div></div></blockquote><div><br></div></div><div>I should also note that the 8% was only on the LLVM tests, where isel is a large chunk of the testing time. Including the clang tests, the difference is around 0.5% (with run-to-run variation).<br>
</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><font color="#888888"><div><br></div><div>Evan</div></font></span><div>
<div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>I'm not sure how CSE factors in here. This propagation happens during legalization. I agree that it should be addressed, but I see it as a separate issue. Unless I'm missing some instance of CSE being performed during legalization?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 4:04 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Mar 15, 2013, at 10:51 AM, Justin Holewinski <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr">Thanks Jakob!<div><br></div><div>Modified patch attached. Anyone adverse to this change?</div>
</div></div></blockquote><div><br></div></div><div><div>+</div><div>+ // Propagate ordering</div><div>+ unsigned Order = DAG.GetOrdering(Op.getNode());</div><div>+ DAG.AssignOrdering(Lo.getNode(), Order);</div><div>+ DAG.AssignOrdering(Hi.getNode(), Order);</div>
<div> </div><div>Did you consider what happens when CSE kicks in? The new nodes may not be new, they could have been CSE'ed with an existing expression.</div><div><br></div><div>When that happens, the ordering should be the earlier of the two.</div>
<div><br></div><div>I think it would make sense to teach the SDNodeOrdering class about this.</div><span><font color="#888888"><div><br></div><div>/jakob</div><div><br></div></font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>
</blockquote></div><blockquote type="cite"><span>_______________________________________________</span><div><br><span>llvm-commits mailing list</span><br><span><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a></span><br>
<span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></span><br></div></blockquote></div></div></blockquote></div></div><span><font color="#888888"><br>
<br clear="all">
<br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>
<span><0001-Propagate-DAG-node-ordering-during-type-legalization.patch></span>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></body></html>