<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 2:42 PM, Raul Silvera <span dir="ltr"><<a href="mailto:rsilvera@google.com" target="_blank">rsilvera@google.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_default" style="font-family:verdana,sans-serif">I had a quick look at the original testcase from Reid, and we're only vectorizing in 32-bit mode. The vectorization cost analysis ends up deciding that there is a small gain to be had (I believe incorrectly).<br>

</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The vectorization cost is computed as the cost of the load, bswap and store. </div>

<div class="gmail_default" style="font-family:verdana,sans-serif">The load and store get cost = -3 each (loading a single v2x64 vs four i32)</div><div class="gmail_default" style="font-family:verdana,sans-serif">The bswap (including overhead) gets cost 4 (6 vector - 2 scalar).</div>

<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Total we get cost 4-3-3=-2 so we vectorize (it vectorizes if cost <0).</div>

<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I think the bug is that the scalarization overhead doesn't take into account the cost of legalizing the vector element type, which in this case incurs additional costs as it is i64 on 32-bit mode. I have a patch that adds the cost of legalizing the element type to BasicTTI::getScalarizationOverhead, and it stops this vectorization (we get cost 12-3-3=6).</div>

<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">If this sounds OK in principle I can submit a patch for review.</div></blockquote>
</div><br>This makes sense to me. Folks can comment on the patch in review if there are cases where this isn't right.</div></div>