<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 May 24, 2013, at 10:08 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On 24 May 2013 17:39, Chad Rosier <span dir="ltr"><<a href="mailto:mcrosier@apple.com" target="_blank">mcrosier@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One side effect of dynamically computing the aliases is that the iterator does not guarantee that the entries are ordered or that duplicates have been removed.<br></blockquote><div><br></div><div style="">Hi Chad,</div><div>
<br></div><div style="">Sounds like you're growing the list (thus the lookup time), rather than shrinking, as I take it was Jacob's original intention?</div></div></div></div></blockquote><div><br></div><div>Jakob suggestion was to remove the static tables, thus shrinking the object file size. Without the static tables, however, we do need to compute the aliases dynamically.</div><div>We're intentionally making a tradeoff between compile-time and object file size with the hope that the overhead of dynamically computing the aliases is minimal. I</div><div>should also note that I'm not actually building/growing any list (i.e., no malloc/free), but rather iterating over the other static tables (i.e., MCRegUnits, MCRegUnitRoots,</div><div>and MCSuperRegs). I'll attach the patch for the curious...</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The documentation seems to imply this is a safe assumption and I haven't found a client that requires these attributes (i.e., strict ordering and uniqueness).<br></blockquote><div><br></div><div style="">I don't think it should matter for the purposes of aliasing.</div></div></div></div></blockquote><div><br></div><div>One would think, but you never know.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also setup a LNT tester and found no execution-time failures on x86 for -O0 and -O2 using the llvm test-suite and externals test-suite (i.e., SPEC95/2K/2K6, etc.).<br>
</blockquote><div><br></div><div style="">I'm wondering why not O3, too? That'll expose vector selection as well, not just VFP, which is a big source of super-registers, at least on ARM. </div></div></div></div></blockquote><div><br></div><div>I'll throw -O3 into the mix.. :) </div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style=""><br></div><div style="">
Somehow it sounds as though you'll find more performance regressions than improvements, but that's my poor assumptions based on nothing concrete. ;)</div></div></div></div></blockquote><div><br></div><div>Jakob also suggested minimizing the use of the MCRegAliasIterator because most of the clients can be rewritten in terms of other iterators. If necessary, I'll</div><div>leave it to Jakob to explain this point further.</div><div><br></div> Chad</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div style="">cheers,</div><div style="">--renato</div>
</div></div></div>
</blockquote></div><br><div></div></body></html>