<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 12, 2012 at 8:34 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@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 class="gmail_extra"><div class="gmail_quote"><div>Hi Michael, Shuxin,</div><div class="im"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">
<div><div>
Shuxin was showing some more complicated patterns that required re-association to match (fast-math flags permitting). For those, we're considering if having a re-associate-for-FMA functionality in codegen-prepare would solve that problem. Thus, we can re-associate in codegen-prepare and emit FMA in fast-isel.</div>

</div></div></blockquote><div><br></div></div><div>Yep. I misread the association on Shuxin's example, but even ((a*b) + (c*d)) + e would match to a 3-instructions:</div><div>(fadd (fma a b (fmul c d)) e).<br></div><div>
<br>
</div><div>If there are hairier examples that really require reassociation my vote would be for this last scheme: An FMA-friendly reassociation pass run before isel that exposes simple patterns for isel to match.</div><span class="HOEnZb"><font color="#888888"><div>
  </div></font></span></div></div></blockquote><div><br></div><div>Agreed. I don't think fast isel should be attempting to form any new patterns.</div><div><br></div><div>-eric </div></div></div>