<div dir="ltr">On Wed, Sep 11, 2013 at 3:49 PM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank" class="cremed">aschwaighofer@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"><div class="im"><br>
On Sep 11, 2013, at 5:30 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>
<br>
><br>
> On Wed, Sep 11, 2013 at 3:17 PM, Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com" class="cremed">aschwaighofer@apple.com</a>> wrote:<br>
> Therefore, I would like to model horizontal reductions as either versions depending on which is deemed cheaper by the cost model.<br>
><br>
</div>> What would make the first pattern cheaper? I'd like to better understand why we don't just all ways do the second form…<br>
<br>
Less shuffles (because shuffle vec, <0,1, undef, undef> is free) so when you don’t have pairwise vector operations the first pattern is preferable.<br></blockquote><div><br></div><div>I thought so, but thanks for confirming. I don't trust myself entirely on the cost models here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> It is a bit unfortunate to not have one canonical form but I don’t think this justifies adding fast-math flags to isel (which will eventually go away).<br>
><br>
> I don't really understand this part.<br>
><br>
> We have some reason at the IR level to know that we can choose either association and get equivalent results. Why isn't the correct answer to pick a canonical form, but preserve that information long enough to reassociate when it is needed?<br>

<br>
</div>We want to pick the right form at ISel time - which is too late to reassociate.<br>
<br>
At some point - before ISel - we have to reasscociate because at ISel time we don’t have the fast-math flags that would tell us that it is legal to reassociate.<br>
<br>
So, we could for example reassociate in CodeGen prepare. We would still need an interface to tell us when to do so.</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Why don't you want to propagate the flags through isel? That really seems like the correct long-term solution: that ISel looks at the pattern, knows that it would be cheaper to use the horizontal instructions and emits the code that way. It doesn't even have to actually *do* the reassociation, it can match the reduction pattern and implicitly re-associate by forming the horizontal instruction pattern. It just needs to know that this is allowed.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">You mentioned not wanting to thread these flags through because some of the machinery is slowly going away, but I think that "slowly" is going to be a *lot* of time. I think threading the flags through is a much better interim cost (fixed, no design overhead) than having 2 patterns in the IR for the same vector operation.</div>
</div>