<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br>On Dec 12, 2012, at 5:20 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div class="gmail_extra">Why not just form them via a fast IR level pass and just have patterns match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass).</div>
<div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>Sorry, we've kind of been jumping around a bit. I'll try to expound on what's being debated: We have a few options ahead of us as far as benefitting fast-isel is concerned.</div><div><br></div><div>We can write a pass to form fmuladds. The intent being to run this very late, perhaps before or part of codegen prepare. The downside here is that it somewhat goes against the point of fast-isel. Fast-isel allows us to skip extra representations of the program, and replacing IR with intrinsic calls is similar to having an extra representation, albeit only for part of the program.</div><div><br></div><div>However, the basic task of spotting an fadd of an fmul is simple enough that fast-isel could just emit the FMA equivalent if it likes. This has the benefit that we avoid the extra representation, but the downside that it makes fast-isel a little more complicated and it only does simple patterns. </div><div><br></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><br></div><br><blockquote type="cite"><div><div class="gmail_extra">-eric<br><br><div class="gmail_quote">On Wed, Dec 12, 2012 at 5:14 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank">milseman@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 style="word-wrap:break-word">Right now we're shying towards having a re-association helper in codegen-prepare that will re-associate expressions (if allowed). This would allow fast-isel to more easily spot FMA opportunities, and form better code.<div>
<div class="h5"><div><br><div><div>On Dec 12, 2012, at 5:11 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><blockquote type="cite"><br><div class="gmail_extra">
<br><br><div class="gmail_quote"><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>You hit send right when I did!</div>
<div>For your example, do you mean that it's grouped like:</div><div>(fadd (fadd (fmul a b) (fmul c d)) e)</div><div><br></div><div>How would your pass go about handling these patterns and is that something that would be too complicated for fast-isel to do on the fly?</div>
</div><br></blockquote></div><br></div><div class="gmail_extra">Depends on how they're grouped, but if the formation happens prior to codegen then fast-isel will just handle whatever new instruction you've got. An example of IR would be useful though :)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-eric</div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></blockquote></div></body></html>