<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 3:11 PM, Fiona Glaser <span dir="ltr"><<a href="mailto:fglaser@apple.com" target="_blank">fglaser@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="adM"><div class=""><div><blockquote type="cite"><div>On Jan 16, 2015, at 3:04 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 2:40 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@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>Well, that may be the conclusion: The performance impact may be within the noise.</div><div>Since this kind of patterns are very specific, this is not surprising.</div><div>For the record, I tend to ignore the tests that run for less than 1 second (too noisy). Then, the noise level is usually around 1% on a quiet computer with fixed frequency, which is not too bad. </div></blockquote></div><br>Numbers would mostly be nice because I don't know if other targets have the thing that makes this such a huge win on x86 -- implicit concat with undef to form 2x-wide vectors.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This may be an x86-specific win, in which case it should just be added as a target-specific combine.</div></div>
</div></blockquote></div><br></div></div><div>Isn’t that typical of SIMD architectures in general? That is, if an arch supports both N and 2N vector sizes, an operation on size-N vectors typically clears the top half, right? Or on armv7-like architectures you can modify d0 and then address q0, right? I’m not super familiar with any architectures other than ARMv7 NEON and SSE/AVX that support multiple native sizes though, so correct me if I’m wrong!</div><div><br></div><div>I guess the worst case would be something like this:</div><div><br></div><div>old pseudocode:</div><div><br></div><div>concat xmm2, xmm0, xmm1</div><div>shuffle ymm3, ymm2</div><div><br></div><div>new pseudocode:</div><div><br></div><div>shuffle xmm2, xmm0, xmm1</div><div>concat xmm2, xmm3</div><div><br></div><div>If the implicit concat isn’t there, and the architecture has no benefit to using smaller shuffles, and the architecture has no two-source shuffle for reasonable element sizes, I guess it could end up with an extra op?</div></blockquote></div><br>I mean, I agree with everything you say, but I know next to nothing about either ARM or PPC's SIMD behavior, so I try not to assume. ;]</div></div>