<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 1, 2014 at 11:55 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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 class=""><div><div>On May 1, 2014, at 11:49 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I'm curious why not to use the def-use tree approach with the SLP vectorizer so that we can also handle bitwise operations as Raul mentioned? That seems like a nice advantage of using an integrated approach.</span></blockquote>
</div><div><br></div></div>I don’t see how the SLP algorithm can recognize these bit ops, which are actually doing a BSWAP. Arnold can probably explain better.</blockquote></div><br>No, this isn't about bswap or this test case.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">It's the more general point that we could view loads, stores, and bitwise operations on M iN values as "vectorizable" into loads, stores, and bitwise operations on a single iN*M value. By doing the widening in SLP, we can expose, for example, the pattern of "load each of four bytes and mask out the high bit before storing it into another array" into "vector" operation on a larger integer.</div>
</div>