<div dir="ltr">On 12 September 2013 15:00, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">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="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">The shuffles for the first form (splitting of vectors) is:</span><br>
</div></div>
<br>
(0,1) <- This one is free.<br>
(2,3)<br>
<br>
while for the second form (pairwise adds) is<br>
(0,2)<br>
(1,3)<br></blockquote><div></div></div><br></div><div class="gmail_extra">Oh, my fault, I read it wrongly. I thought both forms were the same, but the first IR was producing nop-shuffles.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">I agree we need this kind of knowledge in the cost-model, and that it'd benefit more than one arch. I'll check the patch later on...</div><div class="gmail_extra"><br></div><div class="gmail_extra">
I'm also not sure about unsafe-math in the isel, but it strikes me as an important feature to have in. Even if one flag is deprecated, we'll need some form of knowing that during selection, right?</div><div class="gmail_extra">
<br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>