<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 9:59 AM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</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><blockquote type="cite"><span class=""><div>On Nov 13, 2015, at 7:58 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div><br></span><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Nov 12, 2015 at 11:55 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">resistor added a comment.<br>
<span><br>
In <a href="http://reviews.llvm.org/D12345#288471" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12345#288471</a>, @dberlin wrote:<br>
<br>
</span></span><span class="">Would it be reasonable to stage that investigation?  AFAICT the changes already proposed (with Chad's comments incorporated) are a strict improvement, and I at least am seeing pretty severe performance regressions from their absence.  Would you be alright with going ahead and landing those?<br></span></blockquote><span class=""><div><br></div><div><br></div><div>I'm not opposed, I'd like to see compile time numbers first since it transforms reassociate into an iterative algorithm.</div></span></div></div></div></div></blockquote><div><br></div><div>I’ll see what I can get you on that.</div><span class=""><br><blockquote type="cite"><div dir="ltr"><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">For my use case, at least, N-ary reassociation is not really appropriate as I also heavily depend on reassociation of floating point arithmetic. </blockquote><div><br></div><div>I'm not sure why these two statements go together ;-)</div><div>What am i missing?</div></div></div></div></blockquote><div><br></div></span><div>N-ary reassociation depends heavily on SCEV, both in practice and according to Jingyue’s design doc.  SCEV does not work on floating point today, and it seems has an immense undertaking to get it to work on it.</div></div></div></blockquote><div><br></div><div>Sure.</div><div>This is pretty easy to solve though: don't use SCEV for floating point.</div><div><br></div><div>The underlying algorithm is about seeing what chains operations are the same/could be commuted.</div><div> <br></div><div>This does not require SCEV.</div><div>(in fact, you could use GVN's infrastructure if you wnated, for example).</div><div><br></div><div>It uses SCEV because SCEV is great at figuring these things out for integer operations ;-)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>—Owen</div></font></span></div></div></blockquote></div><br></div></div>