<div dir="ltr"><div class="gmail_extra">Hi Jean-Marc,</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) Why does the patch need to define SKIP_CONFIG_H and CUSTOM_MODES at the beginning? I can't see a reason for that.<br><br>A: I just copied them from some CELT optimizations and didn't think too much. Will fix. Thanks!<br><br>2) The whole code is inside an #ifdef FIXED_POINT. It seems like it the file shouldn't be compiled at all for float, so that #ifdef would be unnecessary. Or did I miss something?<br><br>A: Will fix.<br><br></div><div class="gmail_extra">3) The code as it is written is pretty hard to follow. Can you explain at a high level how you're vectorizing this code, i.e. which loop(s) gets unrolled and the general strategy. That should make it easier to follow.<br><br>A: Please see next email.</div><div class="gmail_extra"><br>4) In general I'm a bit skeptical that so much unrolled prolog/epilog code is needed. Did you try having less unrolling for the prolog/epilog? That would be nicer to the I-cache (if possible).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">A: Please see next email.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Linfeng Zhang</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 2:39 PM, Jean-Marc Valin <span dir="ltr"><<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Felicia,<br>
<br>
I've not yet really looked into the details, but first here's a few<br>
comments and questions:<br>
<br>
1) Why does the patch need to define SKIP_CONFIG_H and CUSTOM_MODES at<br>
the beginning? I can't see a reason for that.<br>
<br>
2) The whole code is inside an #ifdef FIXED_POINT. It seems like it the<br>
file shouldn't be compiled at all for float, so that #ifdef would be<br>
unnecessary. Or did I miss something?<br>
<br>
3) The code as it is written is pretty hard to follow. Can you explain<br>
at a high level how you're vectorizing this code, i.e. which loop(s)<br>
gets unrolled and the general strategy. That should make it easier to<br>
follow.<br>
<br>
4) In general I'm a bit skeptical that so much unrolled prolog/epilog<br>
code is needed. Did you try having less unrolling for the prolog/epilog?<br>
That would be nicer to the I-cache (if possible).<br>
<br>
Cheers,<br>
<span class="gmail-im gmail-HOEnZb"><br>
        Jean-Marc<br>
<br>
On 31/01/17 12:30 PM, Felicia Lim wrote:<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">> Hi,<br>
><br>
> Attached is a patch with arm neon optimizations for<br>
> silk_warped_autocorrelation_<wbr>FIX(). Please review.<br>
><br>
> Thanks,<br>
> Felicia<br>
><br>
><br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<wbr>_________________<br>
> opus mailing list<br>
> <a href="mailto:opus@xiph.org">opus@xiph.org</a><br>
> <a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/opus</a><br>
><br>
______________________________<wbr>_________________<br>
opus mailing list<br>
<a href="mailto:opus@xiph.org">opus@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/opus</a><br>
</div></div></blockquote></div><br></div></div>