<div dir="ltr">Timothy / Jean-Marc,<div><br></div><div>In travel, will verify and update full results later on this week.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font face="comic sans ms, sans-serif">Regards,</font><div><font face="comic sans ms, sans-serif">Vish<br></font></div></div></div></div>
<br><div class="gmail_quote">On 11 May 2015 at 10:34, Phil Wang <span dir="ltr"><<a href="mailto:Phil.Wang@arm.com" target="_blank">Phil.Wang@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jean-Marc,<br>
<br>
Thanks for pointing us the way.<br>
Yes it is a overflowing problem. I moved all scaling code in the front of any other operations, and test_unit_mdct passes for all sizes.<br>
I will update Ne10 right after Vish double checks it on hardware. He will repost patches with more verification later this week.<br>
<br>
Regards,<br>
Phil Wang<br>
<br>
Well, I see three questions that need to be answered at this point<br>
1) At what value the overflow starts happening<br>
2) What's the minimum requirement to avoid overflows in the encoder<br>
3) What is causing the overflow to happen much earlier with Neon than<br>
the C code<br>
<br>
Once these three are answered, the solution should be clear.<br>
<br>
Jean-Marc<br>
<br>
<br>
<br>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.<br>
<br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590<br>
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782<br>
<br>
</blockquote></div><br></div></div>